JAVA | Code style and specification

foreword

Recently, I was reading Ali's "Code Out Efficient Java Development Manual" and read the chapter on code style. After working for several years, looking at this chapter again, I found that some code specifications have not been implemented. Large companies pay more attention to code development specifications, but most small companies do not pay so much attention. And these coding habits will follow you for a lifetime. In my opinion, good coding habits will help improve the readability and maintainability of your code, and it is an essential quality for an excellent programmer.

Naming conventions

包名同一使用小写，点分隔符之间有且仅有一个自然语义的英文单词。包名统一使用单数形式, but if the class name has a plural meaning, you can use the plural form.
抽象类命名使用Abstract或Base开头; The exception class name ends with Exception, the test class name starts with the name of the class it is to test, and ends with Test.
类型与中括号紧挨相连来定义数组。
Enumeration class names are suffixed with Enum, 枚举成员名称需要全大写，单词间用下划线隔开.

Naming needs to be clear from the text, so as to reduce the content of annotations and achieve the role of natural explanation. Irregular abbreviations can make code difficult to understand, and even greater sins can lead others in a wrong direction. For example, abbreviate condition as condi, similar abbreviations will reduce the readability of the code.

In general, variable naming needs to meet the small camel case format. But there is a special case, 在定义类成员变量的时候，特别是在POJO类中，针对布尔类型的变量，命名不要加is前缀，否则部门框架解析会引起序列化错误. For example, when defining whether to delete the flag, 成员变量为Boolean isDeleted，它的getter方法也是isDelete()，在框架反向解析的时候，“误以为”对应的属性名是delete，导致获取不到属性，进而抛出异常. However 在数据库建表中，推荐表达是与否的值采用is_xxx的命名方式, in this case, it needs to be set in, and the is_xxx field in the data table is mapped to the attribute Xxx in the POJO class

code display style

indentation

book 推荐使用4个空格缩进，禁止使用Tab键. Because the parsing of tabs in different editors is inconsistent, the visual experience will be different, and spaces are compatible between different editors.

space

The use of spaces is further regulated as follows:

Any binary and ternary operators must be preceded by a space
注释的双斜杠与注释内容之间有且仅有一个空格
方法参数在定义和传入时，多个参数逗号后面必须加空格
If the content in the curly brackets is empty, the simple Ctrip {} will do, and there is no need for newlines and spaces in the curly brackets
There should be no spaces between the left and right parentheses and the adjacent characters inside the brackets
左大括号前需要加空格

Example:

try{
    
    
    // 任何二目，三目运算符的左右两边都必须加一个空格
    boolean condition = (count == 0) ? true : false;

    // 关键词if与左侧小括号之间必须有一个空格
    // 左大括号前需要加空格，左大括号后必须换行
    if (condition) {
    
    
        System.out.println("hello");
        // else 的前后需要加空格
    } else {
    
    
        System.out.println("world");
    }
// 如果大括号中内容为空，则简洁的携程{}即可，大括号内无需换行和空格
} catch (Exception e) {
    
    }

// 方法参数在定义和传入时，多个参数逗号后面必须加空格
String result = getString(one, two, three);

new line

规定单行字符数不超过120个，超出则要换行, line breaks follow the rules below:

operator wraps with the following
The dot notation for method calls wraps with the following
When multiple parameters in a method call need to be wrapped, wrap after the comma
Do not break line before parentheses

The number of method lines 约定一个方法内一般不超过80行, excluding comments, newlines, blank lines, and left and right braces. Only less than 5% of the methods will exceed 80 lines, and these methods usually have room for optimization.

control statement

Braces must be used in if, else, while, do-while, etc. statements. Even when there is only one line of code, braces cannot be omitted.
在条件表达式中不允许有复制操作，也不允许在判断表达式中出现复杂的逻辑组合。
Multi-layer nesting does not exceed three levels, 超过三层的if-else逻辑判断代码，推荐使用卫语句、策略模式、状态模式等来实现.
Avoid using negated logical operators. For example, if(x<10) expresses that x is less than 10, but if(!(x>=10)) cannot be used.

Example guard statement:卫语句就是把复杂的条件表达式拆分成多个条件表达式，比如一个很复杂的表达式，嵌套了好几层的if - then-else语句，转换为多个if语句，实现它的逻辑，这多条的if语句就是卫语句.

if (obj != null) {
    
    
  doSomething();
}
 
转换成卫语句以后的代码如下：
if (obj == null) {
    
    
   return;
}
doSomething();

code comment

Comments on classes, class attributes, and class methods must follow the Javadoc specification, using the format of documentation comments /** */.

Annotations for enums are necessary, and its code is extremely stable. If there is an error in definition and use, it usually has a greater impact.
The content of comments is not limited to explaining the meaning of attribute values, but can also include precautions and business logic.
There are great risks in deleting or modifying enumeration classes. Obsolete attributes cannot be deleted directly, they need to be marked as obsolete, and comments explain the logical considerations and business background of the obsolescence

Single-line comments and multi-line comments, with special emphasis 此类注释不允许写在代码后方, must be written above the code. This is to avoid uneven comments and confusion in the code layout.