The Art of Readable Code

Chapter 1. Code Should Be Easy to Understand

Over the past five years, we have collected hundreds of examples of “bad code” (much of it our own), and analyzed what made it bad, and what principles/techniques were used to make it better. What we noticed is that all of the principles stem from a single theme.

Key Idea

Code should be easy to understand.

We believe this is the most important guiding principle you can use when deciding how to write your code. Throughout the book, we’ll show how to apply this principle to different aspects of your day-to-day coding. But before we begin, we’ll elaborate on this principle and justify why it’s so important.

What Makes Code “Better”?

Most programmers (including the authors) make programming decisions based on gut feel and intuition. We all know that code like this:

for (Node* node = list->head; node != NULL; node = node->next)
    Print(node->data);

is better than code like this:

Node* node = list->head;
if (node == NULL) return;

while (node->next != NULL) {
    Print(node->data);
    node = node->next;
}
if (node != NULL) Print(node->data);

(even though both examples behave exactly the same).

But a lot of times, it’s a tougher choice. For example, is this code:

return exponent >= 0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);

better or worse than:

if (exponent >= 0) { return mantissa * (1 << exponent); } else { return mantissa / (1 << -exponent); } ...