Clean Code book report

I wrote this article to reorganize the contents of the book. So, It doesn’t have any special thing than the original book. Before reading this article, please take note of it.

Chapter 1. Clean Code

Code is the result of specifying requirements as instructions that can be executed by the machine. There is no good or bad code in the machine’s inspection. But, there are bad codes in the programmer’s inspection. When we develop a program, we spend much more time reading existing code than writing new code. That’s why we always have to carefully structure our code to keep it simple and intuitive.

According to experienced programmers, Clean code …

• is simple and intuitive.
• is easy to read and fix even for non-author people.
• gives the impression that someone made it carefully.
• performs the expected functions while reading.

Furthermore, the first well-made code is not everything. You should always keep it clean over time. To prevent the regression of the code, let’s use the Boy Scout rule.

Leave the camping site cleaner than when you first came.

Chapter 2. Meaningful name

A clear description, a big feature of clean code, begins with meaningful names. Don’t spare the time to examine whether there is a better meaningful name.

• Make your intentions clear in the code.
• Avoid false information.
• Separate meaningfully.
• Use a name that is easy to pronounce.
• Use a name that is easy to search.
• For class names and object names, nouns are appropriate.
• For function names, verbs are appropriate.
• Use one world in one concept.
• Use a name from the solution area.
• Use a name from the problem area.
• Add meaningful context.
• Delete unnecessary context.

Chapter 3. Function

Use functions to describe actions in a system.

• Make it small!
• Just do one thing!
• Match the levels of abstraction inside the functions.
• Use the Switch syntax in one place and consider whether it can’t be solved with polymorphism.
• Use a descriptive name.
• Zero is the ideal number of the function arguments.
• Don’t use flag argument. Declare each as a different function.
• Don’t make side effects on the function.
• Separate command and query.
• Use exceptions rather than string error-code.
• Do not repeat!

Chapter 4. Comment

• Comments don’t make up for bad code. Instead, modify your code so that it expresses your intent well.

Heuristic

Comments

• Delete comments about history. Such as source version, issues, and records.
• Delete unnecessary comments.
• Delete commented codes.

Environments

• Build and test your project with just one command.

Function

• The smaller the number of arguments in the function, the better.
• Never use flag argument. Declare each as a different function.

General

• The Principle of Least Surprise. Provide features that take for granted by looking at the name.
• Handle boundaries correctly. Most errors are hidden on there.
• Don’t Repeat Yourself.
• Abstract! Separate high-dimensional concepts from low-dimensional detail implements.
• Design the interface concisely.
• Be consistent with a certain concept.
• Use descriptive variables for readability. Especially, express boolean conditions descriptively.
• Understand algorithms before writing codes.
• Use Polymorphism instead of If/Else or Switch/Case syntax.
• Follow standard notation. There are traditional notation about design pattern and naming.
• Replace magic numbers with constants.
• Place setting information at the top.
• Law of Demeter. Use only modules that you use. Avoid directly using what’s in it.