Importance of Readability

0
447

Why Is Readability So Important?

Readability is the ease with which code can be reader and understand. Why is it so critical to write readable code?

First of all it’s important to acknowledge that as software engineers we spend the overwhelming majority of our time reading code. Whether we fix a bug, add a new feature, or even write new software from scratch, we spend so much time reading code and find the right places to add our changes.

Secondly if the code simple to read, the reader grasps the content very quickly. It is very hard for a bug to hide in that environment. On the other hand it’s much easier for a bug to hide in an impenetrable mess of hardly readable code. Hence increasing the readability of your code is an effective way to reduce the number of bugs significantly.

Thirdly it’s important to recognize that the capacity of the human mind is very limited. It can only focus on a few things at a time. The more our brain is occupied with ugly code, the less capacity we have to think about other things as e.g. the usability of the software or the use case of the customer. Hence increased readability can help to write software that better meets the requirements of the customer.

Last but not least engineers tend to hate code that is hard to read. When I have to work with bad code, I get annoyed and curse in front of my screen. So if you want to make some friends on the team, consider writing readable code.

Writing Speed

Some people argue that it’s important to finish up work quickly and hence no time should be wasted on things like e.g. typing longer, more readable variable names. I agree with the first part, but strongly disagree with the second part. First of all in the long run much more time will be wasted on maintaining hard code, than a few key strokes could ever save.

Second of all I am strongly convinced that the proclaimed goal is not even achieved in the short term. I am much slower to write new code when I bend all the rules than when I care just a little bit about the readability of my code. Simply because it’s easier for me to understand what I am doing. So I do not consider this a valuable argument.

Performance

Some engineers have the habit to try to optimize every single line of code. Optimized code tends to be harder to read than non-optimized code. While the intention is good, usually their efforts have very little returns.

First of all the bulk of execution time usually is made up by a tiny fraction of the code base. So optimizing some logging statement, that is executed once during application startup, will not have any perceivable impact on the performance of the application. Heck it will most likely not even be measurable.

Secondly modern compilers and interpreters do a remarkable job at optimizing code. (On top of that modern CPUs do remarkable things to improve execution time.) So in many instances what looks to you like more efficient code, might not even result in theoretically faster execution.

Lastly if you actually run into performance problems, I suggest profiling your code and work on the code that is to blame for the bulk of the execution time. Working on other parts of the code is simply a waste of time. And it’s so much easier to optimize code, that is easy to read and change, than an ugly mess, that is impossible to understand and easy to break. So I argue that writing readable code actually helps performance when it actually matters.

Attempt to Appear Smart

Some programmers try to impress their colleagues with code that is very hard to read. They believe, that they will be regarded as especially smart and gifted when they produce code that no one else is able to grasp. They use techniques like using obscure variable names, doing as much as possible on one line, use less common language features just for the sake of using them, or solving trivial things by adding uncommon libraries just for the sake of it.

Personally I am not impressed by that kind of code. Neither am I impressed with the amount of problems that tends to accompany that kind of code more often than not.

Conclusion

  • Good readability keeps the costs to develop and maintain software low.
  • Good readability reduces the number of bugs.
  • There are no valid excuses to not put some effort into the readability of your code.
  • Most engineers enjoy readable code. Consider doing your colleagues a favor.