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.
- Use consistent coding conventions, automatically enforced
Code should be formatted the same way and enforced automatically using tools.
- Logic should be in the positive
Logic should ask, "Is this true?" instead of "Is this not true?"
- Separate core logic from the framework
Core logic that is related to solving a business or domain problem should exist outside of a framework.
- Software should be easy to debug
When software behaves unexpectedly, it should be easy to understand what is causing the problem.
- One single source of truth
Data should be held in one location, duplicates of that data should be by reference only.
- Documentation should be close to the code
Documentation, in all forms, should be as close as it can be to the code.
- Code an off-switch
Always plan for a way to switch your work off
- Use meaningful and pronounceable variable names
- Use default arguments instead of short circuiting or conditionals
- 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
- Dependency Inversion Principle
high level modules should not depend on low level modules; both should depend on abstractions.