Clean Code: 7 tips to write clean functions

You know your code is clean when every function does what you expect

Jul 08, 2024

Opportunity For Sponsorship

Exciting News: I'm now accepting sponsorship for this newsletter. If you'd like to promote your brand to an audience of 28,000+ engaged software engineers, read more here.

Motivation

If it takes more than 3 seconds to understand what a function does, it's time to refactor it. The quality of your functions is inversely proportional to the time it takes to understand them.

Complex functions can lead to errors, make changes difficult, and slow down the onboarding process for new developers. Remember, code is read far more often than written, so investing time in writing clean functions is one of the best investments you can make in the long run.

Here are 7 tips on how I write clean functions:

Keep your functions small

As Uncle Bob once said:

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

A function should do one thing and do it well. But what is the ideal function size? There is no hard rule for it. Sometimes 5 lines are just perfect, while other times a function may need 50 lines to achieve a single responsibility.

The best is to always use your judgment based on the context. Be pragmatic, never be dogmatic. The trick is to strive for small functions but avoid making so many that they clutter your code.

Name your functions well

There is no week that I don’t see poorly named functions. Contrary to popular belief, naming your code is not hard. It just requires additional effort, several trials, and continuous refinements.

Here are 4 tips I use to name my functions:

Use intention-revealing naming relating to the business domain. Remember, if your code doesn't speak the customer's language, you’re not focusing on their problems.
Use verb and verb phrases. Using nouns or adjectives for function names can be problematic because they don’t clearly tell what the function does
Use naming conventions within your team
Don't use different terms for the same concept. It makes your code inconsistent, confusing yourself and your colleagues. Instead, use only one word per concept:

Limit the number of parameters

The ideal number of arguments for a function is zero. The problem with functions having too many parameters is that it increases complexity and makes the function harder to test.

Aim for a maximum of three parameters per function. A great solution to this is to group related parameters together:

Reduce nesting with a return early

Avoid using nested IF statements in a function. They add noise and reduce maintainability:

Instead, invert the conditions and use guard clauses. It will make your code easier to follow. As a bonus, you will get rid of the ELSE statements:

Write pure function with no side effects

What is a pure function? A function is pure if it always produces the same result given the same input. Secondly, it has no side effects. In other words, the output depends only on the input while there are no hidden behaviors.

There are 3 benefits of pure functions:

Code is more predictable
They are easier to test
We can run them in parallel

You know you are working on clean code when every function you read does exactly what you expect. Pure functions make your code clean.

Avoid boolean flag parameters

Using booleans as parameters often leads to code that is hard to understand. There are two main problems with it. First, when calling a function with a true or false flag, it’s unclear what the value means. Second, it’s difficult to extend the behavior associated with those flags.

Now, tell me, what is the difference between the following two function calls?

And now tell me, what is the difference between these two:

Instead of booleans, use Enums, making your code self-documenting. Small change, big impact.

Use comments sparingly

When a function is not understandable, don't try to improve it by adding comments. Comments are one of the biggest code smells:

They become easily outdated
They are redundant many times
If used extensively, nobody reads them

Comments are good tools for explaining the WHY, but they should be the last resort for explaining the WHAT. In most cases, you can replace comments by using proper function names. Never forget: A long descriptive name is better than a long descriptive comment.

Summary

Remember: Coding is not just telling the computer what to do. It's telling another programmer what you want the computer to do. My TDD course covers this and much more—helping you become a professional developer who writes quality software confidently.

What you get: