Coding and Code Review Guidelines

In order to reuse code, it must pass the teams measurement of readability and discoverability.

If it is determined that a particular module or code is not reusable, it must be refactored into a “legacy code” area in preparation for deprecation so that it is decoupled from the rest of the codebase.

If you’re making changes to an existing function, you must make a concerted effort to make it testable with a unit test case.

All code changes must be reviewed and approved for transitioning to the next environment by at least 1 other team member, preferably located in a different office in a different city to encourage collaboration.

Code reviewers must discuss and determine if it follows the SOLID principles and if not, the 2 reviewers must agree whether or not that’s acceptable and appropriate at that time before it can go to the next environment.

If code is not formatted and adequately indented such that it’s difficult to read, it MUST be appropriately formatted before continuing.

Consider creating a module when adding new functionality with the intent of unit testing it, making it testable with the least amount of dependencies.

Upon having to modify existing functionality where the code is not in it’s own module, consider creating a new module and moving that code into it.

Variable, module, and function naming is one of the main characteristics that will make code either readable or not. It’s a powerful tool to communicate and document. Consider your names carefully. Follow these guidelines when naming something:

Functions do 1 thing, extract till you drop