control statement
1. [Mandatory] Within a switch block, each case must be terminated by break/return, etc., or a comment indicating which case the program will continue to execute; within a switch block, both A default statement must be included and must be placed at the end, even if it contains no code.
2. [Mandatory] Braces must be used in if / else / for / while / do statements, even if there is only one line of code, avoid using The following form: if (condition) statements;
3. [Recommendation] It is recommended to use else as little as possible. The if - else method can be rewritten as:
if(condition){
...
return obj;
}// Then write the else business logic code;
Explanation:If you have to use if()...else if()...else... method Express logic, [Mandatory] Do not exceed 3 layers, Please use the state design pattern if it exceeds 3 levels.
Positive example: If-else code with more than 3 levels of logic can be implemented using guard statements or state patterns.
4. [Recommendation] In addition to common methods (such as getXxx/isXxx), do not execute other complex statements in conditional judgments to avoid complex logic. The result of the judgment is assigned to a meaningful Boolean variable name to improve readability.
Explanation: The logic in many if statements is quite complex. Readers need to analyze the final result of the conditional expression to understand what
conditions will be executed. What kind of statement, then, would happen if the reader parsed the logical expression incorrectly?
Positive example:
//伪代码如下
boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
...
}Counter example:
if ((file.open(fileName, "w") != null) && (...) || (...)) {
...
}5. [Recommendation] The statements in the loop body should consider performance , try to move the following operations outside the loop for processing, such as defining objects, variables, obtaining database connections, and performing unnecessary try-catch operations (can this try-catch be moved outside the loop)?
#6. [Recommended] Interface input parameter protection. This scenario is common for interfaces used for batch operations.
#7. [Reference] Scenarios that require parameter verification in methods:
1) Methods that are called less frequently.
2) For a method that requires a lot of execution time, the parameter verification time is almost negligible, but if the intermediate execution rolls back or makes an error due to parameter errors, the gain outweighs the loss.
#3) Methods that require extremely high stability and availability.
4) Open interfaces provided to the outside world, whether it is RPC / API / HTTP interface.
5) Sensitive permissions entrance.
8. [Reference] Scenarios where parameter verification is not required in the method:
1) It is not recommended to verify parameters for methods that are very likely to be called cyclically. However, the external parameter check must be noted in the method description.
2) The underlying methods are called frequently and are generally not verified. After all, it is like the last step of pure water filtration. Parameter errors are unlikely to expose problems until they reach the bottom layer. Generally, the DAO layer and Service layer are in the same application and deployed on the same server, so DAO parameter verification can be omitted.
3) A method declared as private will only be called by its own code. If it can be determined that the parameters passed in by the code calling the method have been checked or there are definitely no problems, Parameter verification does not need to be performed at this time.
