Coding Guidelines

#Before Code Commit

##Remove unwanted loggers and console logs before pushing code to pull request.

'Unwanted' - > Any loggers that we added just to debug during development cycle and wont make any sense once they start appearing in server logs in production

#Logging ##Loggers have different levels, lets start using them properly

1. Logger.debug:

   • Debug messages are to help developers debug issues
   • Debug messages need to be added and placed in the right areas within the code which will help debugging and these messages must have proper information to help debugging Example: Logger.debug("Check passed") is a bad debug statement
   • Example: Log.debug(" Candidate name validation check passed for candidate with id " + id); is a well written debug statement

2. Logger.info:

   • Info messages are purely for informational purpose and dont need any action to be taken on them
   • Example: When you want to print something like 'Recruiter with mobile number xxxxxx has requested for 100 credits'

3. Logger.warn:

   • Any warnings that we would want to be aware of if the case were to happen in production (but not necessarily take any action immediately)
   • Example 'Oops, looks like support user xyz is nearing permissible search limit of 1000'
   • Warn messages may be helpful for debugging purpose: Warn messages should point to non-severe issues that the dev team need to act on
   • In an ideal server log - there must be no warn messages

4. Logger.error:

   • All exceptions and errors fall in this category
   • Example:'Static table record not found for given candidate status id. proceeding with default value'
   • Error messages warrant an immediate call for action from dev / dev ops team
   • In an ideal server log - there must be no warn messages

Exception Handling

1. Do not surround an entire method with try-catch block. Try-catch must be closely associated with the piece of code where you expect an exception to occur
2. Do not catch NPE exceptions
3. Do not catch generic 'Exception'

Always qualify which specific exception you are catching . If a piece of code within a try block is expected to throw 3 exceptions, you will have three catch blocks or will include all three exceptions in one catch block. Example:

try {
    // some sql query
}
catch (NonUniqueResultException nuEx) {
}
catch (SqlConstraintViolationException scvEx) {
}
catch (ConcurrentModificationException conEx) {
}

or

try {
    // some sql query
}
catch (NonUniqueResultException nuEx | SqlConstraintViolationException scvEx | ConcurrentModificationException conEx) 
{
}

Design Practices

The design layers

1. ORM Layer (Entity objects)
2. Data Access Layer
3. Services
4. Controllers
5. Http request/response (or protobuf request/response)
6. Client side (html, js, css, Android)

• Each layer above must communicate only with its immediate next layer

Data Access

Every DB entity object must have a corresponding Data Access Object Class

1. DAO class will be responsible for all fetch, save, update and delete operations on it specific entity class
2. Queries that pertain to only a specific entity class will go into the DAO class
3. If the DAO is pertaining to a static table, then the copy of 'constant' for ids pertaining to that static table must reside within the specific DAO class. (Right now we have all these static table constants defined in ServerConstants.java)
4. Queries that require you to join multiple primary entity classes will go into Service class

Controllers

1. Controller class must be the most light weight class
2. No business logic/queries to be written in controller class
3. Controller only delegates a request to various service classes

Coding Convention

Class Organization

1. All public methods to be placed on top of a class
2. Followed by protected methods
3. Followed by private methods

Variable Naming

1. All private/instance variables : myXyz (example: myName, myId)
2. All public static members : XYZ or XYZ_ABC (Example: STATUS_NAME, STATUS)