I remember a couple of years ago, while working with some developers, one of them seemed to be irritated by seeing empty lines in source code. I think he was missing an important dimension of software: Readability. Grab a book nearest to you. Go ahead and do it. Grab any book close to you. Open it on any page. Are there any blank spaces between lines? If you didn’t take a book for kids, empty lines will emerge like crack in the 80’s making paragraphs easier on the eyes (instead of making them red). Speaking of the devil…
I feel better now*. Just as empty lines break ideas up in text books, empty lines in source code offer a new dimension for structuring code. It’s like something that the developer wants to say about the code. Almost like nonverbal communication. I’m exaggerating, but really, use empty lines to separate related lines of code when “ extract method” gets to the limit.
Perfectly refactored code will have only one line per method, which is absolutely a boost in detail complexity. Don’t forget detail complexity! Sometimes we are so concerned with minimizing dynamic complexity that we end up adding tons of detail complexity. 100 methods are harder to read than 20 methods 5 times bigger if you properly place empty lines.
By the way, keep an eye on semantics, use the most suitable words for identifiers, and avoid Hungarian notation. If you need a variable to store the amount of attempts some action is performed, call it attemptsCount (or something similar with two words), don’t use things such as ac, or just count (count of what?). Saving some milliseconds on each key stroke is not as good as saving two or three days of development time plus two or three days of debugging time. Let’s do the math just for fun. When I type attempsCount it takes me like 2 or 3 times more than count. Let’s say 5 times more. If we have to type attemptsCount 1000 times and each time takes 2 seconds, we have a total of 2000s (or 33 minutes). If we have to type count 1000 times and each time takes 0.4s (2s / 5) it will take a total of 400s (or 7 minutes). Total gain using count: 26 minutes. Let’s say half an hour. Now, depending on the context, this could be absolutely nothing or way too much. Are you counting just one thing in your application? if so, count is OK, but I bet that if you are typing count 1000 times, you are counting more than one single thing. So, attemptsCount seems to be more appropriate for real life applications. Just let the code speak by itself.
And remember, it’s not only about complexity and semantics, which in turn determine maintainability. It’s also about writing code that is nice to read and good to programmers’ eyes, if you are not like the aforementioned co-worker, of course. </rant>
* Because of the blank line, don’t get me wrong! I like to keep my neurons intact… well, except for some beers every now and then. By the way, brain cells do regenerate and reproduce, even after maturity. Thanks biologists. Love you, Viviana.
Enjoyed this post? I can help your team implement similar solutions—contact me to learn more.