Relevant Summary of Book
Relevant Summary of Book
#Chapter 3: Functions
1. Functions should be small.
2. Functions should do one thing.
3. Functions should have descriptive names. (Repeated from Chapter 2)
4. Extract code in the body of if/else or switch statements into clearly named functions.
5. Limit the number of arguments a function accepts.
6. If a function needs a lot of configuration arguments, consider combining them into a
single configuration options variable.
7. Functions should be pure, meaning that they don’t have side effects and don’t modify
their input arguments.
8. A function should be a command or a query, but not both (Command Query Separation).
9. Throw errors and exceptions rather than returning error codes.
10. Extract duplicated code into clearly named functions (Don’t Repeat Yourself).
11. Unit tests make refactoring easier.
#Chapter 4: Comments
1. Comments can lie. They can be wrong to begin with, or they can be originally accurate
and then become outdated over time as the related code changes.
2. Use comments to describe why something is written the way it is, not to explain what is
happening.
3. Comments can often be avoided by using clearly named variables and extracting sections
of code into clearly named functions.
4. Prefix your TODO comments in a consistent manner to make searching for them easier.
Revisit and clean up your TODO comments periodically.
5. Don’t use Javadocs just for the sake of using them. Comments that describe what a
method does, what arguments it takes, and what it returns are often redundant at best and
misleading at worst.
6. Comments should include all the relevant info and context someone reading the comment
will need. Don’t be lazy or vague when you write a comment.
7. Journal comments and file author comments are unnecessary due to version control and
git blame.
8. Don’t comment out dead code. Just delete it. If you think you’ll need the code in the
future, that’s what version control is for.
#Chapter 5: Formatting
1. As a team, choose a set of rules for formatting your code and then consistently apply
those rules. It doesn’t matter so much what rules you agree on, but you do need to come
to an agreement.
2. Use an automated code formatter and code linter. Don’t rely on humans to manually
catch and correct each formatting error. This is inefficient, unproductive, and a waste of
time during code reviews.
3. Add vertical whitespace in your code to visually separate related blocks of code. A single
new line between groups is all you need.
4. Small files are easier to read, understand, and navigate than large files.
5. Variables should be declared close to where they’re used. For small functions, this is
usually at the top of the function.
6. Even for short functions or if statements, still format them properly rather than writing
them on a single line.
#Chapter 8: Boundaries
1. Third-party libraries help you ship your product faster by allowing you to outsource
various concerns.
2. Write tests to ensure that your usage of any given third-party library is working properly.
3. Use the Adapter pattern to bridge the gap between a third-party library’s API and the API
you wish it had.
4. Wrapping third-party APIs in a thin layer of abstraction makes it easier to swap out one
library for another in the future. (Repeated from Chapter 7)
5. Wrapping third-party APIs in a thin layer of abstraction makes it easier to mock the
library during testing. (Repeated from Chapter 7)
6. Avoid letting too much of your application know about the particulars of any given third-
party library.
7. It is better to depend on something you control than to depend on something you don’t
control.