Every programmer comes across a point in their career where they think nothing will surprise them or fundamentally change the way they think about code. Every programmer would be wrong. Many programmers often run into these “inflection points” multiple times over the years. One such point came to me while reading the book Clean Code: A Handbook of Agile Software Craftsmanship. The book discussed a few topics involving function and class size as it relates the number of lines of code (loc). Just to get it out of the way now, lines of code really mean very little and should never be used as any kind of metric for the performance or quality of the programmer. But I digress…
I had read many books before that talked about the number of lines in the typical function or class being roughly less than one page size… depending on resolution this could be anywhere from 20-40 lines or more. I was happy to code functions of this size until the book had mentioned making them as small as you can. But what did that exactly mean? Should I be smashing a bunch of normal lines on one line? No, it meant that if you find yourself in a function that seems to be getting the slightest bit lengthy, you probably could break it down further into individual pieces.
The job of a function or class is to do one thing and do it well. The good old mantra of a program unit. I would typically think one thing and doing it well meant I would have one function dedicated to “generating a password”. After all, creating a password is one thing and if the function does it well, I am golden right? Well if this function is beginning to get a bit bulky or too many things are running through your head, do not hesitate one second to break it down into another function. This broken down function may be something that sounds completely unrelated to generating a password. Perhaps this function is a three line function to check if a function parameter is a valid value. Something the generating a password function may use at some point. This extra function may be only a few lines itself and seem so ridiculously simple that you are embarrassed to show anyone. That is ok! If it is named well and does one thing and does it well, who cares if it is small!
I have known programmers, including myself, that sometimes feel that creating a stupidly simple function is amateurish. But we should be striving to have ridiculously simple (and readable) functions because that means those programmers coming down the line later will also know, at a glance, what it does.
This revelation struck me like lightning and so I gave it a try on a few projects. All of a sudden I found that I was writing some much more complex code that just worked the first time. I was a bit shocked at first and thought it couldn’t be. What do you mean I don’t have to debug this? I hammered on it over and over again to get it to break, the thing was solid! Now I have integrated this thought into much of the code I write and I am glad I did. It is always the simplest things that make the greatest impact. Thanks for reading! 🙂
