[閱讀筆記] Clean Code Chapter 17 — Smells and Heuristics

The followings are all the bad things and should be avoided in programming.

Comments

1. Inappropriate Information (meta-data such as authors, last-
   modified-date, SPR number, and so on)
2. Obsolete Comment
3. Redundant Comment
4. Poorly Written Comment
5. Commented-Out Code

Environment

1. Build Requires More Than One Step
2. Tests Require More Than One Step

Functions

1. Too Many Arguments (< 3)
2. Output Arguments
3. Flag Arguments (function does more than one thing)
4. Dead Function (not used function)

General

1. Avoid Multiple Languages in One Source File
2. Avoid Obvious Behavior Is Unimplemented
3. Avoid Incorrect Behavior at the Boundaries (Don’t rely on your intuition)
4. Avoid Overridden Safeties
5. Avoid Duplication (TEMPLATE METHOD, or STRATEGY pattern)
6. Avoid Code at Wrong Level of Abstraction
   - All the lower-level concepts should be in the derivatives and all the higher-levels in the base class
7. Avoid Base Classes Depending on Their Derivatives
   - Base classes should know nothing about their derivatives
   - Exception: the base class has code that selects between the derivatives
   - In general, the deployment of derivatives and bases should be separated
8. Avoid Too Much Information
   - The fewer methods/fewer/instance variables a class has, the better
   - Hide your data/utility functions/constants/temporaries
   - keeping interfaces very tight and very small
9. Avoid Dead Code
   - If/catch try/switch case that never happens
   - Dead code is not completely updated when designs change
10. Avoid Vertical Separation
    Local variables should be declared just above their first usage and should have a small vertical scope
11. Avoid Inconsistency
    Do something a certain way, do all similar things in the same way
12. Avoid Clutter
    Unused variables/uncalled functions/no information comments, etc
13. Avoid Artificial Coupling
    - A coupling between two modules that serves no direct purpose
    - It is a result of putting a variable, constant, or function in a temporarily
    convenient, though inappropriate, location → put them in the right place
14. Avoid Feature Envy
    The methods should be interested in the variables and functions of the class they belong to, and not the variables and functions of other classes
15. Avoid Selector Arguments (true/false, enums, integers, etc)
    - The purpose of a selector argument is difficult to remember and each selector argument combines many functions into one
    - have more functions > pass some code into a function to select the behavior
16. Avoid Obscured Intent (ex. iThsWkd/ iThsRte)
17. Avoid Misplaced Responsibility
    Code should be placed where a reader would naturally expect it to be
18. Avoid Inappropriate Static
    - nonstatic > static methods, When in doubt → nonstatic
    - If you really want a function to be static, make sure that there
    is no chance that you’ll want it to behave polymorphically
19. Use Explanatory Variables
20. Function Names Should Say What They Do
21. Understand the Algorithm → understand how it works
22. Make Logical Dependencies Physical
    Dependent module should not make assumptions (logical dependencies) about the module it depends upon → Explicitly ask that module for all the information it depends upon (physical dependencies)
23. Prefer Polymorphism to If/Else or Switch/Case
24. Follow Standard Conventions
25. Replace Magic Numbers with Named Constants
26. Be Precise
27. Structure over Convention (base classes with abstraction > switch/case)
28. Encapsulate Conditionals
29. Avoid Negative Conditionals
30. Functions Should Do One Thing
31. Do NOT Hide Temporal Couplings
32. Don’t Be Arbitrary
33. Encapsulate Boundary Conditions
34. Functions Should Descend Only One Level of Abstraction
35. Keep Configurable Data at High Levels
    ex. public static final String DEFAULT_PATH = “.”;
36. Avoid Transitive Navigation
    Modules know only about their immediate collaborators and do not know the navigation map of the whole system

Names

1. Choose Descriptive Names
2. Choose Names at the Appropriate Level of Abstraction
3. Use Standard Nomenclature Where Possible
4. Unambiguous Names
5. Use Long Names for Long Scopes
6. Avoid Encodings
7. Names Should Describe Side-Effects

Tests

1. Insufficient Tests
2. Use a Coverage Tool!
3. Don’t Skip Trivial Tests
4. An Ignored Test Is a Question about an Ambiguity
5. Test Boundary Conditions
6. Exhaustively Test Near Bugs
7. Patterns of Failure Are Revealing
8. Test Coverage Patterns Can Be Revealing
9. Tests Should Be Fast