Stop writing essay-sized functions!

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).

Why shorter functions make sense

First, why do we create functions in the first place? The purpose of a function is to perform a specific task, procedure, or routine.

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

Hey, wait!!!
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!

Single Responsibility Principle

Here at DEVREBOOT 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, but the main idea stays the same – each function should only have one single responsibility, or task).

Easier to scan

explain here

When longer functions make sense

explain here

Too many classes

explain here

LOC isn’t the only indicator

explain here

Examples of refactoring long functions

explain here

example 1

explain here

example 2

explain here

example 3

explain here


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.

Adam Allard

Father of 2 - Husband of 1 - Developer of many. I'm a Software Engineer for Northrop Grumman creating web applications for the DoD. Currently I'm primarily working with Java and Angular based applications, although I have some years of experience in various languages and frameworks as well. My hobbies include time with my family, wondering when the Green Bay Packers will win their next Super Bowl, drinking beer that's over-priced, and learning.

Recent Content