Thoughts on Clean Code

I recently decided to pick up Clean Code by Rober C. Martin (a.k.a Uncle Bob). This is one of those seminal books in software development all devs are encouraged to read.

As one of the top selling books on software development since it was published in 2009, there are no shortage of reviews. So I don’t think there’s anything I can add there.

I will just say that I enjoyed it and you should read it. It reinforced many of the things we are already doing and provided me with some new ideas and language around what it means for code to be “clean”.

One negative from my particular vantage is that the examples are all in Java, and as a Javascript developer I feel like I was probably missing out a bit. Which got me Googling and after almost no time I discovered this great GitHub project that applies the principals of Clean Code to Javascript.

One of Uncle Bob’s great strengths is distilling concepts down into pithy aphorisms that you’re more likely remember. Here are my favorites:

Naming

The name of a variable, function, or class should answer all the big questions. It should tell you why it exists, what it does and how it is used. If a name requires a comment then the name does not reveal its intent.

Comments

The proper use of comments is to compensate for our failure to express ourself in code… Comments are always failures. We must have them because we cannot always figure out how to express ourelves without them, but their use is not a cause for celebration.

Functions

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

Functions should do one thing. They should do it well. They should do it only.

Functions should either do something or answer something, but not both.

Dirty code

Nothing has a more profound and log-term degrading effect upon a developmet project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becomeing an inexorable weight that drags the team down.

Successive refinement

To write clean code, you must first write dirty code and then clean it.

Programming ethics

Programmers who satisfy themselves with merely working code are behaving unprofessionally.