In most cases less code is better. "The best code is no code at all." - Jeff Atwood.
Googling "less code is better" gives some good articles about the statement. I would list some of them here:
- Why Less Is More When It Comes to Code
- The Best Code is No Code At All
- Why Less Code Is More
- Write Less Code
- Code is Liability, the Less the Better
And some other:
Instead of a disclaimer: "Readability matters, and you should not sacrifice readability in order to get less code." (c) Daan
In this particular article I would like to describe my view on the special case of having less code. That is having less lines of code. Although strictly speaking it is possible to have less lines of code with the same, less and even more code itself.
Here are some reasons why I would prefer less lines of code (without sacrificing readability):
- Vertically more compact code
- Less need for vertical scrolling
- Smaller commit diffs
- Possibly less code
The most important reasons are "Vertically more compact code" and "Less need for code scrolling". Both reasons let you reduce the number of bugs (per feature) and also code faster.
Vertically more compact code lets you see more source code at a time. And therefore frees your brain capacity from remembering the code that is currently not shown on the screen. The freed brain capacity can be used for analyzing the code and being more attentive which results in faster development and less bugs respectively.
Less need for vertical scrolling also results into less bugs because it reduces brain distractions on the scrollings. There are also some little saving because scrolling the code does require some actual time to do the scrolling. Also scrolling may introduce human factor bugs because of mislooking parts of the code related to their vertical position in a file.
Several years ago I read some research conclusions backing the above claims, but unfortunately I could not find proof links for them now. Please, submit links in comments if you have them.
There are some techniques to reduce negative effects of having many code lines:
- Second, third, etc monitor (especially vertically positioned)
- Smaller font sizes, so more code lines can fit vertically on a screen
- Breaking long files into several smaller ones
Each of these techniques should be used if possible in addition, but not as a replacement to less code lines. And here is why.
Extra monitors is a great option. I remember I read a research conclusion that an extra monitor might increase productivity up to 30%. Unfortunately, although extra monitors help to reduce amount of computer interface interactions (scrolling and switching between files) they still do not completely solve the focus and attention issue. Because a human still able to look at only one screen at a time even if several of them are in front. Another issue with extra monitors is that they limit your mobility which might be important for those who often work on a laptop from different places (basically the extra monitor option might be just not option for such users).
Smaller font size let you display more lines on the same screen, but at an expense of more load on eyes. Which may be undesirable for health reasons and in fact make your eyes getting tired faster.
Breaking long files into several smaller ones solves a need for scrolling by a need for switching between files. Which may be a better option, but still has a drawback of distracting developer's attention for extra interface interactions.
There is something else about having more lines. When reading the code line by line every line switch requires some brain capacity for understanding if the next lines expressing another logical construct of the language or a continuation of the current one. As an example I would put a multiple line function or method call. So with each next line you read you need to understand if it is still the same function call that started several lines above or a new function call or statement. Therefore the less lines there are the less times you need figure out if you are still in the same logic construct or there is a new one started.
Based on the above explanation I would like to provide some otherwise questionable code style decisions that I prefer.
Multiline one-liners
Prefer:
value = (value_for_true() if some_looooooooooooong_expression(arg) else
value_for_false())over:
if some_looooooooooooong_expression(arg):
value = value_for_true()
else:
value = value_for_false()This is an example of the same code size, but different number of lines. The preferred variant is 2 lines less and twice smaller. I should point out that the preferred variant is intact with Google Python Style Guide.
Condensed function/method calls
Prefer:
value = function(long_name_arg1, long_name_arg2,
long_name_kwarg1=value1, long_name_kwarg2=value2)over:
value = function(
long_name_arg1, long_name_arg2,
long_name_kwarg1=value1, long_name_kwarg2=value2)and especially over:
value = function(
long_name_arg1,
long_name_arg2,
long_name_kwarg1=value1,
long_name_kwarg2=value2,
)All the above snippets are PEP8 complaint. But with preferred one we can save up to 4 lines and make the code up to 3 times lines shorter.
