More on this book
Community
Kindle Notes & Highlights
God is in the details,
Code, without tests, is not clean. No matter how elegant it is, no matter how readable and accessible, if it hath not tests, it be unclean.
It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!
Change one variable name for the better, break up one function that’s a little too large, eliminate one small bit of duplication, clean up one composite if statement.
The word variable should never appear in a variable name.
A class name should not be a verb.
Methods should have verb or verb phrase names
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
Functions should hardly ever be 20 lines long.
if statements, else statements, while statements, and so on should be one line long.
FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.
The parts we ignore are where the bugs will hide.
“Don’t comment bad code—rewrite it.”
Every time you write a comment, you should grimace and feel the failure of your ability of expression.
Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments.
it’s simply a matter of creating a function that says the same thing as the comment you want to write.
Don’t Use a Comment When You Can Use a Function or a Variable
an upper limit of 500.
Small files are usually easier to understand than large files are.
Instance variables, on the other hand, should be declared at the top of the class.
If one function calls another, they should be vertically close, and the caller should be above the callee, if at all possible.
we expect the most important concepts to come first, and we expect them to be expressed with the least amount of polluting detail. We expect the low-level details to come last.
A team of developers should agree upon a single formatting style, and then every member of that team should use that style.
Error handling is important,
If you are tempted to return null from a method, consider throwing an exception or returning a SPECIAL CASE object instead.
Returning null from methods is bad, but passing null into methods is worse. Unless you are working with an API which expects you to pass null, you should avoid passing null in your code whenever possible.
Third-party code helps us get more functionality delivered in less time.
Test code is just as important as production code.
What makes a clean test? Three things. Readability, readability, and readability.
we want to test a single concept in each test function. We don’t want long test functions that go testing one miscellaneous thing after another.
test just one concept per test function.
The tests should have a boolean output.
we should implement only today’s stories, then refactor and expand the system to implement new stories tomorrow.
designing everything up front before implementing anything at all.
According to Kent, a design is “simple” if it follows these rules: • Runs all the tests • Contains no duplication • Expresses the intent of the programmer • Minimizes the number of classes and methods The rules are given in order of importance.
Do not lock regions of code that do not need to be locked.
It is best not to write a comment that will become obsolete.
Comments should say things that the code cannot say for itself.
A comment worth writing is worth writing well. If you are going to write a comment, take the time to make sure it is the best comment you can write.
When you see commented-out code, delete it! Don’t worry, the source code control system still remembers it. If anyone really needs it,
You should be able to run all the unit tests with just one command.
Functions should have a small number of arguments. No argument is best, followed by one, two, and three. More than three is very questionable and should be avoided with prejudice.
Boolean arguments loudly declare that the function does more than one thing. They are confusing and should be eliminated.
G5: Duplication This is one of the most important rules in this book, and you should take it very seriously. Virtually every author who writes about software design mentions this rule.
The fewer methods a class has, the better. The fewer variables a function knows about, the better. The fewer instance variables a class has, the better.
Dead code is code that isn’t executed.
You find it in the catch block of a try that never throws.
G10: Vertical Separation
Variables and function should be defined close to where they are used. Local variables should be declared just above their first usage and should have a small vertical scope. We don’t want local variables declared hundreds of lines distant from their usages.
The team should not need a document to describe these conventions because their code provides the examples.
