Clean Code: A Handbook of Agile Software Craftsmanship

Description: Clean Code describes the principles, patterns, and practices of writing clean code. Every serious programmer should read this book. Each page is full of amazing insights into what it means to write quality code.

Copyright: Pearson Education, Inc.

Author: Robert C. Martin

Website: Visit

My Notebook

Passages that I highlighted in my physical book, or thought were important.

100% Complete

It's your job to defend the code.

Takeaway: This really resonated with me. Code that is thought out and written well is paramount in preventing codebases that will eventually become unwieldy. It is a developer’s job to communicate why taking the time to do things right the first time is so important.

Clean code is focused.

Takeaway: You can tell if code was written well if you can’t find distracting details littered throughout. Functions, classes, and modules should have a “single-minded attitude”.

Code should be matter-of-fact as opposed to speculative. It should only contain what is necessary.

Takeaway: Write your code in a controlled and decisive manner. Discipline is important.

Clean code makes it easy for other people to enhance it.

Takeaway: A quote from Dave Thomas asserts that clean code should be easy to read and enhanced by a developer other than the original author. We should all remember this when writing code. We are partially writing it for whoever comes after us.

Clean code always looks like it was written by someone who cares.

Takeaway: Someone who cares about the cleanliness of their code will take the time to think it through and write it in a way that leaves no obvious improvements to be seen.

When the same thing is done over and over, it’s a sign that there is an idea in our mind that is not well represented in the code.

Takeaway: This has to do with duplication. Simple code shouldn’t contain any. It should express the design and ideas of the system in a way that is clear and sensible. A good developer will plan ahead and write their code in a way that doesn’t require any duplication.

Code should be obvious, simple, and compelling.

Takeaway: When you read code you shouldn’t be surprised by anything it contains. It shouldn’t take much effort to figure out what the code is doing and why. A truly talented programmer will make their code look ridiculously simple.

The next time you write a line of code, remember you are an author, writing for readers who will judge your effort.

Takeaway: Programmers are responsible for communicating their thoughts and ideas. Take pride in your work and think of writing code as if you were writing it for the world to see. Write your code in a way that makes you proud and eager to show to anyone that will listen.

We are constantly reading old code as part of the effort to write new code.

Takeaway: Write your code in a way that is easy to read. It should be expressive and have a flow to it. When you come back and read it later you’ll be happy you took the time to write your code in an expressive way.

Leave the campground cleaner than we found it.

Takeaway: Be proactive! Small improvements over time keeps code from degrading. Change a variable name to be more descriptive, break a large function into smaller pieces, eliminate some duplication, etc.

Names should reveal intent.

Takeaway: Choosing the right name for a class, method, function, etc. takes time but is well worth it. The names you choose should describe what your code does. Also, don’t be afraid to change a name if you can think of a better one.

If a name requires a comment, then the name does not reveal its intent.

Takeaway: The names you use should be declarative and expressive. Ideally, they should make it so that no comment better describes what your code is doing.

Avoid leaving false clues that obscure the meaning of code.

Takeaway: Avoid words whose meaning varies from the intended meaning. Don’t name a variable accountList unless it is actually a list.

Beware of using names which vary in small ways.

Takeaway: Do your best to avoid using names that are not easily differentiated. Robert C. Martin asks how long it takes to tell the difference between XYZControllerForEfficientHandlingOfStrings and XYZControllerForEfficientStorageOfStrings. The point being that the two have a similar shape, and you can’t quickly identify the difference without making an effort.

Noise words are another meaningless distinction.

Takeaway: Uncle Bob is talking about choosing names for your code that has meaningful distinctions. His example of noise words are classes called Product, ProductInfo, and ProductData. The names for these classes are meaningless because we don’t know for sure what each is doing differently.

Distinguish names in such a way that the reader knows what the differences offer.

Takeaway: It is extremely important to take time when choosing names for your code. Be sure to choose names that leave no question about the functionality. The names you use should also clearly distinguish differences.

If you can’t pronounce [the name], you can’t discuss it without sounding like an idiot.

Takeaway: The names you choose for your code should make sense and be readable. You don’t want to use names that only mean something to you, or your team. Someone looking at your code in the future probably won’t have any idea what you were thinking.

Single-letter names and numeric constants have a particular problem in that they are not easy to locate across a body of text.

Takeaway: A single-letter name or number isn't descriptive, is misleading, and can show up in searches for other things. Do your best to avoid hard-coding values and single-letter names. A constant named "MAX_CLASSES_PER_STUDENT" is easier to understand (and find) than just the number 7.

I have worked for some interesting companies. Learn more about my work experience!
I like to spend my spare time working on personal projects and keeping up with the latest trends. See some of my latest projects!