Code Style Guide and Review Standards
- 1.
- 2.
- 3.Run SonarLint. It checks for >600 rules that can be found on SonarSource. These rules are identified like this:
RSPEC-12345
.
Implementations.
- 1.
- 2.Add a TODO for removing the feature toggle after A/B testing. Best practices of implementing feature toggles can be found here.
- 3.File extension names should represent the syntax (e.g.,
.json
), rather than the semantics (e.g.,.content
,.expected
,.test
).- Mitigation: If you really want, use double-extension names, such as
.expected.json
. - Why: So that automated tools can kick in and verify the syntax.
- 4.
- Example:
TODO(SRCH-12345): Change the function signature here after Feature B is enabled.
- Mitigation: If you absolutely cannot create a Jira Ticket for this TODO, use your username instead:
// TODO([email protected]): Refactor this block of code into its own function when the demand increases.
. - Why: Jira should be the only tool for task management.
Tests.
- 1.Distinguish between test doubles. Dummies, fakes, stubs, spies, and mocks all have different meanings.
- 2.
- When: When testing a method that returns a complex object, you may choose to compare the returned object with an object parsed from a JSON file.
- Why: JSON is order-insensitive, and you should not compare JSON strings line-by-line.