Function length

Throughout my career I have heard many arguments about the length of the function. The deeper question is when should the code be placed in a separate function? Sometimes recommendations are based on size, for example, the function should fit on the screen. Others are based on reuse - any code used more than once must be moved to a separate function. But if the code is used only once, then you can leave it in place. It seems to me that the argument about the separation of intent and realization has a big meaning. If you need to spend time searching for a piece of code to understand what it is doing, then you need to put it into a function and give it a name that answers the “what” question. Then the next time the meaning of the function will be immediately obvious, and in most cases you will not be bothered by how the function performs its work. In other words, what happens in the function body.

When I began to apply this principle, I developed the habit of writing very small functions — usually not more than a few lines. Any function longer than six lines already smacks. It’s quite common for me to have a function with one line of code. Kent Beck once showed me an example from the original Smalltalk system, and it helped me to really understand that size is not important. Smalltalk in those years worked on black and white cars. If you needed to highlight text or graphics, you had to reverse the video. The class in Smalltalk, which is responsible for graphics, contained the 'highlight' method, and in its implementation there was only one line - the call to the 'reverse' method. The name of the method was longer than the implementation, but it did not matter, because there was a long distance between the intention and the implementation of this code.

Some people worry about short functions because they care about the impact of calls on performance. When I was young, it sometimes mattered, but today it is rare. Optimizing compilers often work better with short functions because they are easier to cache. As usual, general recommendations make sense in optimizing performance. Sometimes the right decision is to return the code from the function back to its original place. But often the presence of small functions allows you to find other ways to optimize. I remember when people were against having the isEmpty method for lists. The standard way was aList.length == 0. But here is the case when the function name indicates intent, and this can help with performance if there is a faster way to determine the void of the collection than by checking the length.

Small functions like this work only if the names are good enough, so you need to pay attention to this. Over time, your skill will improve, and this approach can greatly enhance the self-documentation of the code. Functions of a higher level can be read as a story, and the reader chooses which functions to go into if you need to know the details.