Keeping it short

Tips for making and keeping your functions small

Using Lines of Code (LoC) for measuring developer productivity is a well known poor metric; roughly equivalent to measuring success in building aeroplanes by weight of the planes produced.

However looking into LoC in a code base can be a powerful proxy for technical debt issues and issues of complexity when considering a single file, class, module or a function.

Long functions or methods typically violate good coding practices by exhibiting the following issues

In this short article I want to cover some basic tips and techniques that you can apply to existing code bases to refactor long functions. More importantly you can apply these as you are writing your code preventing the technical debt accruing in the first place.

This is by far the easiest way to keep the size of your functions small and might seem almost trivial but it provides other benefits you may not consider initially.

When adding a piece of functionality, rather than appending the code to the bottom of the current function, why not create a new function with that added functionality, a descriptive name and call it from the function that was initially to receive the code instead.

Say we had the following simple function for finding an area of a rectangle

If we then get asked to add something such as simple logging we could do this

This is probably fine as we still only have less than a handful of lines but for the sake of this point we could instead do this

Our total number of lines has increased but our functions have remained small which was our aim. Also you might notice we’ve created a reusable function to log dimensions that could be helpful for other functions we might implement.

Most importantly for me though we’ve made reading the area function easier, I can quickly decide whether I’m interested in the logging part of the code, if not I can skip over the single line rather than attempting to interpret what the code is trying to accomplish.

Say we had the following naive function for turning a traffic light from red to green.

Let’s look at how we could use this for an existing piece of code

By extracting some methods we could reduce this to

We started with 14 lines (17 with comments) and ended up with 20 total. Our longest function however went from 12 to 7 which is a very nice reduction.

You might have also noticed that I removed the comments after having chosen descriptive function names instead.

Many modern languages also allow for anonymous inline functions as we saw in the traffic light example above

Whilst very useful; I’ve found that they are often a main culprit for long hard to read functions as we hide actions and concepts that could be better named and extracted out.

Let’s do this bit of refactoring for our traffic light code from above

In this scenario we’ve only increased our total line count by 1 but our longest function is now only 3 lines long.

Passing a named function instead of an anonymous inline one makes the intent explicit and means we don’t have to analyse the contents to determine whether or not it is of interest to us.

How long is too long? That depends on a number of factors ranging from the language you are working in to the business domain and team preferences.

Personally for me when working with modern expressive programming languages around 5 lines is a good length that’s easily achievable.

There are some easy to spot indicators that might hint at a function that is too long:

With these two very simple extractions you should be able to not just keep your functions short but also make your code more expressive and easier to reason about.

What I really like about these techniques is that you should be able to apply both of these to new code quickly to prevent long functions in the first place but also to your existing code without undertaking extensive refactoring or restructuring of your code.

I’d love to hear about your experiences with keeping your functions short, I’m planning the next part with more advanced techniques so if you have a technique or a tip to share get in touch.

Related posts:

Mysten Labs is pleased to announce the release of public Sui DevNet! This is the first of several Sui test networks we will launch and a big step in offering robust services to developers and…

Customers are a vital ingredient for the success of every organization. The feat of this objective depends on how a company invests in its clients and their customers’ experiences. Acquiring a tool…

One of the first things people say to you when you tell them you were bullied at school is ”oh, everyone gets bullied.” Or even worse, you get told to ignore them. Just try and move on. Almost as bad…