Naming Conventions
- When naming methods, variables, etc. use camel case starting with a lowercase letter, e.g. mySampleMethod.
When naming custom Errors/Exceptions, use camel case starting with an uppercase letter, e.g. CustomRuntimeException. - Make names easy to read and descriptive, but maintain brevity as much as possible. For example:
- Yes - postLoginRequestService
- No - postLoginRequestWithUsernameAndPasswordByDefault
Code Formatting
- Use tabs for indentation, with tabs set at 2 spaces.
- Use inline comments to clarify complex logic, as well as to summarize code blocks.
- Use empty lines to separate logical blocks of code.
Coding Style
- Do not reuse parameters for multiple purposes, instead create new parameters for each us case.
- Use overloading when method/function can be called with multiple sets of parameters as much as possible, instead of creating new method names.
- Default values used in code, should not be passed as parameters but set in the code. If the method should allow overriding the default value with a parameter, then use overloading. For example:
myMethod() {
return myMethod(5);
}
myMethod(int value) {
// doLogic
}
- Minimize code repetition and create utility functions for common functionality. This will also minimise potential errors and simplify unit testing.
Logging
- Create Utility functions to abstract complexity of each logging call.
- Make the logging level (e.g. INFO, WARNING etc.) dynamic so it can be set at deployment time or even modified at runtime.
- Log each message at its appropriate logging level, e.g. an exception should be logged as a WARNING or ERROR, and the contents of a message as a DEBUG message to help during development or troubleshooting.
- Pay attention to the information included in logging messages. Potential PII data should not be logged, or should be encrypted or masked before being logged.
- Higher environments (e.g. PROD) should have limited logging restricted to messages necessary for auditing and alerting.