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.

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.

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.