clean code summary

General rules

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

Design rules

• Keep configurable data at high levels.
• Prefer polymorphism to if/else or switch/case.
• Separate multi-threading code.
• Prevent over-configurability.
• Use dependency injection.
• Follow Law of Demeter. A class should know only it’s direct dependencies.

Functions rules

• Small.
• Do one thing.
• Use descriptive names.
• Prefer fewer arguments.
• Have no side effects.
• Don’t use flag arguments. Split method into several independent methods that can be called from the client without the flag.

Comments rules

• Always try to explain yourself in code.
• Don’t be redundant.
• Don’t add obvious noise.
• Don’t use closing brace comments.
• Don’t comment out code. Just remove.
• Use as explanation of intent.
• Use as clarification of code.

Understandability tips

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

Names rules

• Choose descriptive and unambiguous names.
• Make meaningful distinction.

Objects and data structures

• Hide internal structure.

• Prefer data structures.

• Avoid hybrids structures (half object and half data).

• Should be small.

• Do one thing.

• Small number of instance variables.

• Base class should know nothing about their derivatives.

• Better to have many functions than to pass some code into a function to select a behavior.

• Prefer non-static methods to static methods.
  Tests

• One assert per test.

Tests

• One assert per test.

• Readable.

• Fast.

• Independent.

• Repeatable.
  Code smells

• Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.

• Fragility. The software breaks in many places due to a single change.

• Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.

• Needless Complexity.

• Needless Repetition.

• Opacity. The code is hard to understand.