General

• Use Coding conventions
• Keep it simple, stupid (KISS)
• Boy Scout Rule: “Always leave the campground cleaner than you found it” - Robert C. Martin
• Broken Window Theory: Don’t Live with Broken Windows
• Fix root cause (root cause analysis, no workaraounds): otherwise it will get you again
• You aren’t gonna need it (YAGNI): implement things when you need them

Class Design

SOLID

• S: Single responsibility principle (only one reason to change)
• O: Open/closed principle (open for extension, closed for modification)
• L: Liskov substitution principle
• I: Interface segregation principle
• D: Dependency inversion principle (dependency injection can be used)

See SOLID and SOLID Design Principles.

Package Design

See Package principles

Package Cohesion

Reuse-release Equivalence Principle (REP)

• A package must contain reusable classes
• All of the classes inside the package are reusable (or none of them are)
• The classes must be of the same family

Common-Reuse Principle (CRP)

Classes that are reused together belong in the same package

Common-Closure Principle (CCP)

• A package should not have more than one reason to change
• Changes to an application shall occur only in one package
• If classes are tightly coupled, they belong to the same package

Package Coupling

Acyclic Dependencies Principle (ADP)

• No cycles are allowed in the dependency structure
• Dependencies form a tree (or DAG)

Stable-Dependencies Principle (SDP)

• Packages that are changed frequently shall not depend on packages that are difficult to change

Stable-Abstractions Principle (SAP)

• Stable packages should be abstract, so that it can be easier extended
• Unstable packages should be concrete, it’s easier to change

Development Environment and Infrastructure

• Building the software needs to be possible with just one command
• Running a single test needs to be possible with just one command
• Running all tests needs to be possible with just one command
• Integrate unit tests into build
• Source control (e.g. git) for everything: source, docs, reference data, tools…
• Use static and dynamic analysis tools
• Set highest warning level of compilers, use multiple different compilers
• Write documentation: Wiki, Doxygen, Markdown…
• Apply CI/CD, pipeline as code

References

• 97 Things Every Programmer Should Know
• Encapsulate what varies (Encapsulation Is Not Information Hiding)
• Prefer Composition to inheritance
• Program to Interface, not Implementation: Liskov substitution principle
• Cohesion: Objects should only interact with ‘friends’ (objects in their neighborhood)
• Ineracting Objects should aim for loose coupling
• Tell don’t ask: Tell Objects what to do with their data, don’t ask for the data to operate on it
• List of Design Patterns