What does a “good code” look like according to Linus Torvalds?

Aug 02, 2017
Blog

In his recent interview, Linus Torvalds made a quick remark about programming with “good taste”. Good taste? The interviewer wanted more details and Linus didn’t let him down.

He introduced a code snippet. It wasn’t the code of «good taste». This code was an example of poor taste to show some contrast.

This function, written in C, which removes the object out of the linked list. It contains 10 lines of code.

Torvalds drew attention to the very bottom. It was the if-statement that he criticized.
Linus explained, that there were two cases of removing an object from the linked list, which required attention.

If the object was located at the beginning of the list, the process of removing would differ from the process when it was in the middle of the list. This was the reason for “poor taste” in the if-statement.
But if he said that it was necessary, why was it that bad then?

Later, he showed the second slide to the audience. It was his example of the same function but written with “good taste”.

The original 10 lines of the code reduced to 4.
But those lines didn’t matter. The reason was in the if-statement. It disappeared. It was not necessary anymore. The code was refactored in the way that the removal process would not depend on the object position in the list.

If you carefully study the code, it becomes evident. The second slide was better. The idea that this conditional statement can be removed doesn’t bear in mind at once.

This illustration will teach you a more efficient way of removing the object from the linked list. Besides, it will make you think about writing your code in a totally different key. It will stop being just a set of algorithms sprinkled throughout the entire program.

From Linus statements, one can conclude that the matter of “good taste” is the removal of the edge case, which often behaves as conditional statements. The fewer conditional operators you have, the “tastier” your code is.

Shall we try to look at a relative project where the code is also written in C?

Initializing grid edges

There’s an algorithm below written to initialize the points along the grid edges, presented as a multidimensional array: grid[rows][cols]

Again, the aim of this code was to initialize the points’ values, which are located on the edge of the grid – only the top row, bottom row, left column and right column.

To achieve it, a developer initially looped over every point and used conditionals to check the boundaries. It looked this way:

for (i = 0; i < GRID_SIZE * 4; ++i) {
    // top edge
    if (i < GRID_SIZE)
        grid[0][i] = 0;
    // right edge
    else if (i < GRID_SIZE * 2)
        grid[i - GRID_SIZE][GRID_SIZE - 1] = 0;
    // left edge
    else if (i < GRID_SIZE * 3)
        grid[i - (GRID_SIZE * 2)][0] = 0;
    // bottom edge
    else
        grid[GRID_SIZE - 1][i - (GRID_SIZE * 3)] = 0;
}

It worked, but there were some obvious troubles with the construct.

  1. Complexity — the use of 4 conditional operators inside 2 loops seemed to be too complicated.
  2. Efficiency — taking into account that GRID_SIZE had the meaning of 64, this loop fulfilled 4096 iterations to set values for 256 edge points only.

Linus would probably say it wasn’t very “tasty”.
I had to work a bit. I managed to simplify one more loop with 4 conditions. The improvement was slight, considering the total difficulty, but it was sufficient for performance because it performed only 256 iterations in the loop, one per each point along the edge.

for (i = 0; i < GRID_SIZE * 4; ++i) {
    // top edge
    if (i < GRID_SIZE)
        grid[0][i] = 0;
    // right edge
    else if (i < GRID_SIZE * 2)
        grid[i - GRID_SIZE][GRID_SIZE - 1] = 0;
    // left edge
    else if (i < GRID_SIZE * 3)
        grid[i - (GRID_SIZE * 2)][0] = 0;
    // bottom edge
    else
        grid[GRID_SIZE - 1][i - (GRID_SIZE * 3)] = 0;
}

Better, yes. But it all looked ugly. It wasn’t the code easy to read and easy to follow.
Could it still be improved? It obviously could. The solution was surprisingly simple and elegant. It was hard to believe, but I needed just little time to find it.

Below there’s the final code version. It has one “for” loop and not a single condition. Moreover, the loop performs only 64 iterations. It dramatically improves both complexity and efficiency.

for (i = 0; i < GRID_SIZE; ++i) {
    //  top edge
    grid[0][i] = 0;
    // bottom edge
    grid[GRID_SIZE - 1][i] = 0;
    // left edge
    grid[i][0] = 0;
    // right edge
    grid[i][GRID_SIZE - 1] = 0;
}

This code initializes 4 different edge points for each loop iteration. It’s easy. It’s very efficient. It’s easy to read. In comparison with the original version, and even with the second version, they look like day and night.

So, does this code have a good taste?

Could be. But the mentioned example is not the issue because programming with a “good taste” is more than any code snippet. Linus himself said, that his own example was far too little, to illustrate his point of view.

Probably, Linus means that the developers with “good taste” do something in a different way, spending time on the concept of what they create, before to start. They define the object boundaries they work with and the way the objects interact with each other. They try to ensure ideal matching and elegant performing.
Their result looks like the Lunus’s example of “good taste”, but in a broader scope.

 

Previous articleNext article