Clean code and the art of readable code a summary

Readable code is a subject of discussion among developers aiming to improve their code skills and also thinking about the human side of the code, indeed, the machine executes the code and doesn’t care about the readability or maintainability of the code, instead, this chore, is part of the daily life of programmers. Readability can be interpreted in different ways by different people, therefore, there are initiatives to at least create a common sense. [1].

Previously I reviewed the book “The Art of Readable Code” [2], this time, the focus is to compare the differences and similarities between “The art of readable code” and “Clean Code”. Despite both books being opinionated, they provide a common ground for developers to build on top of and begin a discussion around that.

Naming things

The first subject addressed here is the naming convention that is stated by both books to be important, with the argument being that we are coding for humans and not for machines. The study path created by [3] gives a point of attention for naming as well, as it is one of the sections listed to be read on the Clean code book.

Not only that, David Thomas and Andrew Hunt dedicated a section to talk about naming things in code, they also agree that naming is hard and renaming is even harder. What caught my attention is the story behind the i, j and k convention for loops, the convention came from 60 years ago as it was part of the FORTRAN language. Even though this became as standard across the industry (you see today still loops with those variables) they are not that helpful when reading code.

Furthermore [4] also points to a not-so-productive way of improving code understanding with obvious comments:

Low level comments, on the other hand, such as “Increment i (by one)” after a line that reads i++; , can create a burden on the chunking process.

The Programmer’s Brain by Felienne Hermans, pg 28

Besides that, she also agrees that naming things is hard. For that, she elaborates on previous research to understand why is that the case. For further elaboration on this, I would recommend some bits of the programmer’s brain review.