During a recent code review, I found myself having trouble reading through a function written by one of my peers. I came to realize that this one function was taking care of a few different tasks. This one function was way too long and should’ve been broken up into smaller, simpler routines.
As I was segregating the different responsibilities into their own functions, I began to wonder how I’d best explain my rationale of the code changes to my team. I started to ask myself:
- How long should a function be?
- What is the maximum lines of code a method should be?
- What is the ideal length of a routine?
Turns out, there’s no real black and white answer. If your team is following a style guide, then there should be plenty of real concrete answers to most common programming questions like:
“how many spaces should you indent your CSS code?”
“should you use tabs or spaces for indentation?”
However the answer to how many lines of code a function should be is really left up to debate. Generally speaking though, most people agree that functions should be small with a single responsibility, (although some make the case for longer functions, which I’ll discuss later in this article).
You can use my affiliate link to get your own copy of the “Clean Code: A Handbook of Agile Software Craftsmanship” on Amazon!
>>> Click here to order on Amazon!
Why shorter functions make sense
Let’s first start out by asking the question, “why do we create functions in the first place?” The purpose of a function is to isolate a specific task, procedure, or routine that needs to be performed.
Often times there are repetitive tasks that we don’t want to repeat (adhering to the DRY principle), so we’ll throw those repetitive tasks into one or more functions.
Other times, we just want to organize our code so it’s easier to read, easier to scan, and easier to maintain.
In Robert “Uncle Bob” Martin’s book, “Clean Code”, he states:
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.Robert “Uncle Bob” Martin – Clean Code
Single Responsibility Principle
Here at Pragmatic Ways, we love reminding people of common Software Engineering Principles. One of the most popular and widely accepted principles is the Single Responsibility Principle (SRP).
The SRP is the first principle in the SOLID principle set. As its name suggests, it means that each class/ module should be focused on one and only one specific task.
(Note: this is a very generic view of the Single Responsibility Principle, and SRP really pertains more to constructing and organizing classes rather than functions, as well as the idea that a class should only have a “single reason to change”, but the main idea stays the same – each function should only have one single responsibility or task).
Easier to scan
For the most part, the small a function (or class) is, the easier it is to read. And as an experienced programmer, what should be the most important thing to keep in mind when writing code?
Write code that’s easy to understand!
Change is inevitable in the software world. That’s why it’s called “soft” ware. If it wasn’t meant to change, then it wouldn’t be software in the first place, it would be hardware.
With change, means someone (possibly even you) will have to someday change it. And it is insanely frustrating trying to read someone else’s code that you have no clue what’s going on!
Smaller functions will naturally help other developers literally “read” your code instead of trying to “understand” your code. The function names should be logical enough to explain the entire purpose of the function, thus allowing for easy scanning of code.
A developer should be able to very quickly and easily scan the code by just looking at the function name and signature to have a good idea of what the code is supposed to be doing. The longer the function, the harder it is to generalize its purpose with a single function name.
When longer functions make sense
Too many classes
LOC isn’t the only indicator
Examples of refactoring long functions
More often than not, shorter functions are better than longer functions. Realistically though, there is no correct answer to how long a function should be. An 80 line method can be just as maintainable as a 10 line method, and a 4 line method could be just as hard to read as a 100 line method.
The key point to remember is that a function should have one single responsibility. Generally speaking, most functions should be smaller in nature in order to maintain this single responsibility principle. If your function starts going over 20 lines, then you may want to take a quick step back and analyze if your code is performing more than one responsibility.