Clean Code – How Simple Is That?

Recently, I gave a talk about clean code, where I said that “Simple is better than complex”. It is! Today I want to talk about how we read code, and what we consider as simple code. And that goes for both production and automation code.

Did you ever think about why it’s called Code? Whatever we’re building, eventually becomes 0-s and 1-s. The Code part is the abstraction from the computer’s side of the table. Our code abstracts binary numbers.

Sometimes it’s also abstracting other things. Like meaning. Have you ever looked at code, and asked “who would write this garbage”? The problem becomes worse when finding out today, that it was us, 3 months ago.

There are a lot of principles of clean code (which I teach, check the Clean Code workshop). A fundemental one is simplicity. Because simple code is easy to understand.

Here’s a bit of code:

public class Factorial
{
    public int Calculate(int number)
    {
        if (number <= 1)
            return number;
        else
            return Calculate(number - 1) * number;
    }
}Code language: PHP (php)

Do you consider this code simple?

When I ask this in my classes, people first identify the name (Factorial), then the method (Calculate). Aha! It calculates factorials, and it does this as a recursion.

Then the attendees stop to think about the question. It’s only 5-6 lines of code. Looks simple enough. But then they think about the recursion.

And recursion is not simple, is it? Even if it looks simple.

Simple Code, Complex Code or Clean Code?

What makes it complex? One issue, is the code runs differently than how it looks.

Think about it, when we read code, it’s from top to bottom. We roll the movie (not unlike Forest here), in our brains. We trace through the steps in our mind. First this happens, then the next line does that.

But with recursion it doesn’t actually work like that. We understand that, and we identify that as code complexity. This complexity comes with costs we know: More time to understand, more risks, more testing and debugging.

And bugs. more bugs.

Not Run-of-the-Mill Code

You know what other code has these properties as well?

Concurrent code. When different threads running through the code, it’s not line-by-line. Our experience tells us that this is risky business. Concurrency, thread safety – all these are complex.

No, I’m not suggesting writing one giant god-mode functions that do everything line by line. Our brains don’t deal with those too well either.

Plus, we wouldn’t like to lose the performance benefits of concurrency, just because we don’t know for sure what line runs when.

But, if you’re designing something that solves a complex issue, remember that there are design options. Some are more simple than others. Simplify the design. When you’re coding it, simplify the code. And when you’re reviewing code like that, simplify it further.

Smart code may work, sometime. But it also causes maintenance headaches. It introduces risks, debugging, and as a rule, impacts time-to-market, and not in a good way.

Simple is better than complex. We should have more of that.

And like I said, Clean Code is usually simple. And a whole lot more! Check out my workshop.