Journey through Clean Code — Chapter 1: Clean Code

Vicky Leong
Aug 17, 2017 · 3 min read

I’ve been wanting to read this Robert C. Martin’s (Uncle Bob) book because the notion really speaks to me as someone who thinks of himself as (or dreams to be) a craftsman or an artist as opposed to ninjas and rockstars (https://m.signalvnoise.com/i-m-a-boring-programmer-and-proud-of-it-d4ac3dd2defe). I finally made time for it! And here’s my quick takeaway from the first chapter:


As long as it works to the specs and the deadlines are met, does it really matter how the code is written? Uncle Bob says “yes”, because bad code costs a heck of a lot more than you think (emphasis is mine). Does this sound familiar?

Every addition or modification to the system requires that the tangles, twists, and knots be “understood” so that more tangles, twists, and knots can be added.

Be honest. Which project(s) came to mind when you read that? Here are some things he alludes to as the real cost of bad code:

  1. More bad code
  2. Frustrated developers
  3. Bugs
  4. Productivity, as the mess builds up
  5. Crashes
  6. Crappy product
  7. Frustrated customers
  8. The existence of the company

If you think “the project manager”, “my boss”, “tight schedule”, or “the clients”, you are mistaken according to Uncle Bob. Developers’ unprofessionalism is to blame. He drove that point home with this analogy: If a patient demanded that a surgeon “stop all the silly hand-washing in preparation for surgery because it was taking too much time,” would it be a professional thing for the surgeon to buckle to such demand knowing full-well the risk?

But what about deadlines? We agree that bad code slow us down, so we write bad code to go faster. Uncle Bob argues that professional developers understand that the second part of that statement is false. The only way to go fast is to keep code as clean as possible at all times.

Our author asks this question to very well-known programmers: Bjarne Stroustrup, inventor of C++; Grady Booch, author of Object Oriented Analysis and Design with Application; and “Big” Dave Thomas, founder of OTI, godfather of the Eclipse strategy among others. The essence of their answers are as follow:

  • Elegant — pleasing to read
  • Efficient — no wasted cycles
  • Exhibits close attention to details — good names, complete error handling
  • Focused — does one thing well
  • Readable — to human, reveals obvious solution
  • Crisp — decisive, matter-of-fact
  • Easy to change — by others
  • Has tests
  • Minimal — smaller is better, no duplications
  • Cared for
  • Tiny abstractions
  • Pretty much what you expected — no surprises, obvious

Practice, practice, practice. It’s one thing to be able to tell if a piece of code is bad, it’s another to write a good piece of code. A lot of people can tell if a picture looks bad, but not a lot of people can draw good picture. It takes practice, discipline, and painstakingly mastering little techniques to develop a “code-sense”.

(Reading this book is part of it.)

It is not enough to write clean code, however. Code rots over time. Therefore, developers must take responsibility to keep the code clean by “leaving the campground cleaner than you found it.” In practice, this would be improving a variable name, eliminate one small bit of duplication, clean up one nested if statement, or break up a big function every time you check your code in.

This book does not promise to give us developers “code-sense”, but it will teach us some techniques, tools, and thought processes to writing good, clean, professional code. We’ll start that on the next chapter.

Stay tuned.

Vicky Leong

Written by

Becoming a better front-end engineer one day at a time.