Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- 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.
Add Comment
Please, Sign In to add comment