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
Passages that I highlighted in my physical book, or thought were important.
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.
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”.
Takeaway: Write your code in a controlled and decisive manner. Discipline is important.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Takeaway: Avoid words whose meaning varies from the intended meaning. Don’t name a variable accountList unless it is actually a list.
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.
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.
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.
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.
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.