Readability vs. Succinctness

When it comes to best practices in writing code, there are a lot of thing to consider. Correct indentation for methods and classes, appropriate spacing between functions and variables, and clear names for each variable and method. Some best practices also have a limit on how many lines each method or class should be. But this can cause trouble if it makes you think that less lines of code is always better. This can cause people to sacrifice readability for succinctness.

The main reason you should follow best practices while writing code is because it increases readability. Even if your code does exactly what it is supposed to do, it isn’t good code if it’s indecipherable. Good code needs to be something another developer (or you looking back at it months or years later) can read and understand without too much trouble. The guidelines about the length of your code are just another best practice designed to help with readability. The idea is that, if your method is too long, it is probably trying to do too much and the functionality should probably be split into more than one method.

It can be satisfying to write a one-line method, because to seems so simple and succinct. But sometimes, putting too much functionality in one line can be unclear. For example in Ruby you could write this:

def do_stuff(array)
array.select { |num| num % 2 == 0 }
.map { |sum, num| num % 4 == 0 ? sum + num / 2 : sum + num }
end

This is kind of a pointless function that finds all the even numbers of an array, then sums all of the even numbers while dividing any number that is divisible by 4 in half. But that isn’t necessarily clear at first glance. It can take a minute to figure out what exactly this function is doing, especially because the function name is not descriptive. A clearer way of writing this method would look like this:

def sum_evens_with_halving_on_fours(array)
evens = array.select { |num| num % 2 == 0 }
halved_fours = evens.map { |even| num % 4 == 0 ? even / 2 : even }
halved_fours.map { |sum, num| sum + num }
end

By splitting the functionality into a few lines and adding in clear names for the method and variables, it is obvious right away what the purpose of this method is. Another example of an ambiguous method is this:

def more_stuff(array)
array.map do |num|
sum = 0
while num != 0
sum += num % 10
num /= 10
end
sum
end.select { |num| num % 2 == 1}
end

This is another method without any obvious names to tell you what is going on. First, it maps all of the numbers in the array to the sum of their digits, then it returns an array of all of the odd number’s sums. In this case, even though the method isn’t very long, it would still make more sense to have a separate method for the functionality that sums the digits of the number. Why is that? Because it is a process that can be separated from the functionality of this method, and it is also something you might want to use somewhere else. A better way to write the functionality of this method could look like this:

def odd_summed_digits(array)
summed_digits = array.map { |num| sum_digits(num) }
summed_digits.select { |num| num % 2 == 1}
def sum_digits(num)
sum = 0
while num != 0
sum += num % 10
num /= 10
end
sum
end

Once again, the clear names of the variables and methods make it more obvious what is going on. And in this case, splitting the method into two gives a distinct purpose for each method.

In conclusion, the length of your code can have a big impact on readability. If you are too concerned about making your code shorter and more succinct, you may make it harder to read, and ultimately bad code that other people wouldn’t want to work with. Making your code shorter is only okay as long as you don’t sacrifice readability for succinctness.

Written by

Software Engineer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store