Intro

I received a book in the mail today, paid for by my employer: Clean Code by Robert C. Martin. It promises to be a hard read, a deep dive, and NOT a "feel good" book. I was just in the right mind set today to feel up for the challenge of consuming it. So that's what I'm doing: challenging myself to read, digest, and grow from this book.

I was also in just the right mind set to start (yet another) project to work through alongside this book. This project will remain unnamed for now, but a coworker (who actually pointed me to the guy to buy this book for me) mentioned the idea and I said I was going to build it. So here I am: building a stupid, yet fun little project to expand my skills.

So, I want to keep notes as I read, talk about my thoughts, and put them down somewhere so I can come back to them. What better way that to put it on my website for all to see?

Get On With It!

Enough with the introductions, let's talk about the book! I read chapter 1 today (as well as the foreword). Let's first go over some of the sentences I highlighted, and what I got from them.

"Code is anti-evil, and clean code is perhaps divine."

This one comes from the foreword by James O. Coplien. Coplien talks a lot about where our modern principles and workflow in the software development industry comes from: Japanese auto manufacturers. He goes on to say that there's still even more we can learn from the industry, looking at home much time is spent on maintenance vs. manufacturing. Indeed, that's also the case in software development.

Mr. Coplien has a lot to say on fine details, and how worth it, how righteous it is to focus on them. God is in the details, he believes. He tells us how this book has copious amounts of code and how some might think it odd. Aren't we past looking at code? Shouldn't we talk about concepts and abstractions? "No!" he seems to say. This book talks about code because that's where it becomes good, not in the abstraction. He says "Richard Gabriel advises us in his essay, "Abstraction Descant" that abstraction is evil. Code is anti-evil, and clean code is perhaps divine." So this book gets into the nitty-gritty. It shows us code and tears it apart line by line, keyword by keyword because that's how you can write good, clean, divine code. Not by studying grand concepts, but by worrying about the God in the details.

"And specifying requirements in such detail that a machine can execute them is programming. Such a specification is code."

From the section "There Will Be Code". Martin briefly touches on the notion that some people believe we'll get to a point where we won't need to write code, and just how absurd that thought it. If you need to specify exact thoughts and order of operations in some sort of language for a computer to understand, no matter how high level that language ends up being, you're still writing code. I was nodding along quite violently to this section because I've read this exact sentiment before. I agreed with it in the past, and I agree with it here.

This quote doesn't really help in the goal of what I want from this book, but I think it's something that bears repeating.

"Later equals never."

LeBlanc's law. Do it right the first time because later will never happen. If it's worth writing, it's worth writing correctly the first time. We are the stewards of code, and writing it wrong means we shouldn't have written it at all.

A few sections later, Martin lists the typical excuses we give as programmers for why we wrote bad code. "I was rushed", "The requirements changed too much", "The sales team promised too much". He proposes: "so what?", and then poses this question: "what if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time?". We are the doctor, and management/sales/whoever is the patient. We cannot comply with this request. As such, we cannot comply with rushing to write bad code, and must defend good code with great passion. Anything else is unprofessional.

"No matter how elegant it is, no matter how readable and accessible, if it hath not tests, it be unclean."

Even if this quote does remind me of Captain Barbossa from Pirates of the Caribbean, it's still correct. Untested code is not good code. It has not gone through the gauntlet that tests provide and the introspection that comes from writing tests. I don't have much to say that this quote doesn't say already, so let's get to the next quote.

"...making it easier to read actually makes it easier to write."

This comes after Martin talks about how much time we spend reading code versus actually writing it: well over 10 to 1. We're constantly referencing code we've already written while writing new code. So, making it easier to read means it's going to be easier to write more later on. It's really a simple concept, but I've never really thought that much about it. This quote opened my eyes, and it really made me excited to see what this book has to offer. I really think this one could really sum up everything I've read so far.

One more quote that I think is really important for the health of whatever project or product we work on.

"If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot."

"...simple could not rot." I love that. It's so hopeful, definitive, and accurate all at one. He says this right after quoting a rule from the Boy Scouts of America: "Leave the campground cleaner than you found it." Now, having been a Boy Scout myself might make me a sucker for this second to last section of the first chapter, but I think it leaves us with something simple. When we're writing code into an existing class, file, whatever, why can't we just take a few minutes to clean up a bit? We don't have to fret over a major change and go bug our manager or anything. No one in code review is going to question why you renamed a variable better or simplified an if statement when it pertains to what you're already doing. They might even smirk, nod, and have just a touch brighter day knowing their coworker cares.

Summary

This first chapter has me excited to see what's in store for me in the following chapters. I'm ready for the challenge that this book presents, and I plan to keep posting as I read more of this book. Even if no one reads this, I think it's important for me to write because it helps me digest what I just read. I've always thought that if you can teach a concept to someone and help them learn it, then that means you understand it as well. So I guess that's what I'm trying to do here: teach a ghost of blog reader's past how to write good code, or at least, understand how this book tries to convey it. Martin doesn't promise that this book will teach us to write good code. He promises to "show [us] the thought processes of good programmers and the tricks, techniques, and tools that they use." So maybe I won't teach this ghost to write good code, but maybe I can teach them the same that Martin promises to show us.

Until next time.