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 of Uncle Bob’s great strengths is distilling concepts down into pithy aphorisms that you’re more likely remember. Here are my favorites:
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.
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.
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.
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.
To write clean code, you must first write dirty code and then clean it.
Programmers who satisfy themselves with merely working code are behaving unprofessionally.