Summary of 'Clean code' by Robert C. Martin

clean_code.md

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules

1. Keep configurable data at high levels.
2. Prefer polymorphism to if/else or switch/case.
3. Separate multi-threading code.
4. Prevent over-configurability.
5. Use dependency injection.
6. Follow Law of Demeter. A class should know only its direct dependencies.

Understandability tips

1. Be consistent. If you do something a certain way, do all similar things in the same way.
2. Use explanatory variables.
3. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
4. Prefer dedicated value objects to primitive type.
5. Avoid logical dependency. Don't write methods which works correctly depending on something else in the same class.
6. Avoid negative conditionals.

Names rules

1. Choose descriptive and unambiguous names.
   • They are a powerful tool, use them communicate with others.
2. Make meaningful distinction.
   • Always communicate your intent, if you have to put a comment, your name is a bad one.
3. Avoid disinformation
   • A name must says what it means, and means what it says
   • Remember, people will have to talk about your code
4. Use pronounceable names
   • If you have to read the code to understand the meaning, it's a bad name.
5. Avoid encoding.
   • Encodings are distracting. They obfuscate the code. They make it hard to read
   • No Hungarian Notation, "m_", "p_"
6. Clean code should always read like well-written prose
   • Classes: noun
   • Variables: nouns
   • Methods: Verb names. If they're Booleans, make them predicates.
   • Make sure that when you write a line of code, it looks like and reads like a sentence.
7. Scope rule
   • Variable names: short, even one letter, if they're in a tiny little scope, but variable names should be long if they're in a big long scope.
   • Function names: short if they've got a long scope. Long and descriptive, if they have a short scope.
   • Classes names. Short names for public classes. Longer names for private classes in tiny scopes.