(from Building Maintainable Software by Joost Visser. Some notes are verbatim Joost's, others are rewritten by me based on my understanding of his concepts.
Shorter units (functions, in most languages) are easier to analyze, test, and reuse.
Units with fewer decision points (conditional branches) are easier to analyze and test.
Duplication of code (including literals) should be avoided at all times, since changes will need to be made to each copy. Duplication is also a source of regression bugs.
Units with fewer parameters are easier to test and reuse
TODO: write something about complexity (amount of state coder needs to keep in their head) per-unit and per-module
Modules that are loosely coupled are easier to modify and evolve
Top-level business logic components that are more loosely coupled are easier to modify, and lead to a more modular system
A well balanced architecture, with not too many and not too few components, of uniform size, is the most modular and enables easy modification through separation of concerns.
A large system is difficult to maintain because more code needs to be analyzed, changed, and tested. Also, maintenance productivity per line of code is lower in a large system than in a small system.
- leave no unit-level code smells behind
- long units
- branching units
- units /w large interfaces
- leave no bad comments behind
- leave no code in comments behind
- leave no dead code behind
- leave no long identifier names behind
- leave no magic constants behind
- leave no badly handled exceptions / error cases behind