1. [Mandatory] In a switch block, each case should be finished by break/return. If not, a note should be included to describe at which case it will stop. Within every switch block, a default statement must be present, even if it is empty.

2. [Mandatory] Braces are used with if, else, for, do and while statements, even if the body contains only a single statement. Avoid using the following example:

    if (condition) statements;

3. [Recommended] Use else as less as possible, if-else statements could be replaced by:

if (condition) {
    ...
    return obj;  
}  
// other logic codes in else could be moved here

Note: If statements like if()...else if()...else... have to be used to express the logic, [Mandatory] nested conditional level should not be more than three.

Positive example: if-else code with over three nested conditional levels can be replaced by guard statements or State Design Pattern. Example of guard statement:

public void today() {
    if (isBusy()) {
        System.out.println("Change time.");
        return;
    }
    if (isFree()) {
        System.out.println("Go to travel.");
        return;
    }
    System.out.println("Stay at home to learn Alibaba Java Coding Guidelines.");
    return;
}

4. [Recommended] Do not use complicated statements in conditional statements (except for frequently used methods like getXxx/isXxx). Use boolean variables to store results of complicated statements temporarily will increase the code’s readability.

Note: Logic within many if statements are very complicated. Readers need to analyze the final results of the conditional expression to decide what statement will be executed in certain conditions.

Positive example:

// please refer to the pseudo-code as follows 
boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
    ...
}

Counter example:

if ((file.open(fileName, "w") != null) && (...) || (...)) {
    ...
}

5. [Recommended] Performance should be considered when loop statements are used. The following operations are better to be processed outside the loop statement, including object and variable declaration, database connection, try-catch statements.

6. [Recommended] Size of input parameters should be checked, especially for batch operations.

7. [For Reference] Input parameters should be checked in following scenarios:
  1) Low-frequency implemented methods.
  2) Overhead of parameter checking could be ignored in long-time execution methods, but if illegal parameters lead to exception, the loss outweighs the gain. Therefore, parameter checking is still recommended in long-time execution methods.
  3) Methods that needs extremely high stability or availability.
  4) Open API methods, including RPC/API/HTTP.
  5) Authority related methods.

8. [For Reference] Cases that input parameters do not require validation:
  1) Methods very likely to be implemented in loops. A note should be included informing that parameter check should be done externally.
  2) Methods in bottom layers are very frequently called so generally do not need to be checked. e.g. If DAO layer and Service layer is deployed in the same server, parameter check in DAO layer can be omitted.
  3) Private methods that can only be implemented internally, if all parameters are checked or manageable.