Code Style Guide and Review Standards
- 3.Run SonarLint. It checks for >600 rules that can be found on SonarSource. These rules are identified like this:
- 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.,
- Mitigation: If you really want, use double-extension names, such as
- Why: So that automated tools can kick in and verify the syntax.
- 4.TODOs should include a Jira Ticket ID. Derived from Google C++ Style.
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.
- 1.Distinguish between test doubles. Dummies, fakes, stubs, spies, and mocks all have different meanings.
isEqualToComparingFieldByFieldRecursivelyfrom AssertJ to compare two complex objects.
- 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.