Code review principles
When code reviewing, link the principle to the problem you see in the code. Instead of writing long comments and explaining why a particular design decision isn't the right choice, link to principles that provide relevant information for discussion.
- Documentation should be close to the code
Documentation, in all forms, should be as close as it can be to the code. - Software should be easy to debug
When software behaves unexpectedly, it should be easy to understand what is causing the problem. - Use default arguments instead of short circuiting or conditionals
- Use meaningful and pronounceable variable names
- Dependency Inversion Principle
high level modules should not depend on low level modules; both should depend on abstractions. - One single source of truth
Data should be held in one location, duplicates of that data should be by reference only. - Code an off-switch
Always plan for a way to switch your work off - Separate core logic from the framework
Core logic that is related to solving a business or domain problem should exist outside of a framework. - Single-Responsibility Principle
Every module, class or function in a computer program should have responsibility over a single part of that program's functionality, and it should encapsulate that part - Logic should be in the positive
Logic should ask, "Is this true?" instead of "Is this not true?" - Use consistent coding conventions, automatically enforced
Code should be formatted the same way and enforced automatically using tools.