Java coding standard
As a highly compelling programmer, you should know these Java coding standards !!!
Foreword
The coding standard is "Mandarin" in the programming world, which is very important for every programmer. Because in the development and use of a project, most of the time is spent on maintenance, and software maintenance is usually not done by the original developer. The coding specifications can increase the readability of the code, making software development and maintenance more convenient. These specifications are the basic rules that every programmer should abide by, and it is also the practice that people in the industry have always obeyed silently.
Writing code according to coding standards is a basic condition for being a good programmer. The following summarizes some coding standards in Java (refer to Tencent coding standards):
1. Basic Specifications
1. The class name must be modified with public
2. Write only one statement per line
3. The part enclosed by "{}" identifies a certain level of the program structure "{" is generally placed at the end of the start line of this structure, "} "Align with the first letter of the beginning line of the institution, and occupy a line by itself.
4. Statements or comments at the lower level should be indented by several spaces than statements or comments at the higher level, so that the program is clearer and more readable.
Second, java file organization
File organization rules: Since programs with more than 2000 lines are difficult to read, programs with more than 2000 lines should be avoided as much as possible. A Java source file contains a single public class or interface. If private classes and interfaces are associated with a public class, you can put them in the same source file as the public class. The public class must be the first class or interface in this file.
3. The order of file organization:
1. File comments: All source files should have a comment at the beginning, which lists the file ’s copyright statement, file name, function description, and creation and modification records:
2. Package and import statements: In most Java source files, The first non-comment line is the package statement. It can be followed by the lead package statement
3. Class or interface annotations: Use JavaDoc documentation annotations, which should be annotated before class and interface definitions, including class and interface descriptions, latest modifiers, version numbers, reference links, etc .;
4. Class or interface declaration
5. Class or interface implementation notes: If the information about the class or interface is not suitable as a "class or interface documentation note", it can be given in the class or interface implementation note;
6. (Static) Variables: First, public variables of the class, then protected variables, then package-level variables (without access modifiers), and finally private variables;
7. Instance variables: first, public level, then Protection level, then package level (no access modifier), and finally private level;
8. Construction method;
9. Ordinary method: methods should be grouped by function, not by scope or access authority Grouped.
Note: JavaDoc documentation notes: describe Java classes, interfaces, constructors, methods, and fields. Each document comment will be placed in the comment delimiter, a comment corresponding to a class, interface or member. This comment should be placed before the statement. The first line of the document comment does not need to be indented, and subsequent document comments are indented by 1 space (align the asterisk vertically).
Four, code style
1. Indentation: The program block should be written in indent style. Indentation only uses the TAB key, not the space bar (Please set TAB to 4 in the editor); the beginning of the method body, the definition of the class, and if, The code in the for, do, while, switch, and case statements must be indented;
2. Alignment: the delimiter of the program block, the left curly brace "{" and the right curly brace "}" are on a separate line and should be exclusive to each One line and in the same column, at the same time left aligned with the statement referencing them; alignment only uses the TAB key, not the space bar; it is not allowed to write multiple short statements in one line, that is, only one statement per line; if, for, do , While, case, switch, default and other statements on their own line.
3. Line break: A line with a length of more than 80 characters requires line
breaks. The line break rules are as follows: break after a comma; break
before an operator;
long expressions should divide new lines at low-priority operators;
new lines Indent 2 TAB.
4. Interval: Between classes, methods and relatively independent program blocks, blank lines must be added after variable descriptions; spaces should be left after keywords, and keywords such as if, for, while, etc. should be left with a space and then left parenthesis " (", To highlight the keyword; the method name and its left parenthesis" ("Do not leave a space between to distinguish it from the keyword; binary operators such as" = "," + = ""> = "," <= " , "+", "*", "%", "&&", "||", "<<", "^", etc. should be added with spaces; unary operators such as "!", "~", " ++ ","-"No spaces before and after; xiang" []]
5. Notes
1. Principle: @Deprecated must be noted for classes and methods that have been deprecated, and alternative classes or methods should be described; for methods for collections and switches, it should be indicated in the method comments whether they are multi-thread safe.
2. Field comment: Adopt JavaDoc document comment, the field defined as public must be given a comment, before the definition of the class (static) variable and instance variable, it should be commented, and the description of the field should be given:
3. Method comment: adopt JavaDoc documentation comments, should be annotated before the method definition, including method description, input, output and return value description, throwing exception description, reference link, etc .:
Six, naming rules
1. Basic rules: use complete English descriptors that can accurately describe variables, fields, classes, interfaces, packages, etc .; use mixed case to improve the readability of the name; use terminology in the field; use abbreviations as little as possible, but if Be sure to use, when using public abbreviations and custom abbreviations, etc .; avoid using names that are similar or differ only in case.
2. Package naming: the package name is always lowercase, less abbreviations and long names are used; the following rules apply:
[基本包].[项目名].[模块名].[子模块名]...
Classes should not be defined directly under the basic package. All classes and interfaces in the project should be defined in their respective projects and module packages.
3. Class or interface naming: The name of a class or interface is a noun, mixed case, with the first letter of each word capitalized. Try to make your class name concise and informative. Use complete words and avoid abbreviations (unless the abbreviation is more widely used, like URL, HTML).
4. Variable naming: mixed capitalization, the first letter of the first word is lowercase, and the first letter of the following word is uppercase; variable names should not start with an underscore or a dollar sign; try to avoid single-character variable names unless they are One-time temporary variables. Temporary variables are usually named i, j, k, m, and n, which are generally used for integer types; c, d, e, which are generally used for character types; without using the Hungarian naming rule, it is not easy to clearly identify the variable Type variables should use type names or type name abbreviations as their suffixes; component or component variables use their type names or type name abbreviations as their suffixes; collection type variables, such as arrays and vectors, should be named with plural numbers or use Noun as a suffix.
5. Constant naming: All capitals are used, and words are separated by underscores.
6. Method naming: The method name is a verb, mixed case, the first letter of the first word is lowercase, then the first letter of the word is capitalized; the value class can use the get prefix, the set class can use the set prefix, judgment Classes can be prefixed with is (has).
7. Statement
1. The reputation of a class or interface: The syntax of class and interface definitions is as follows
[Visibility] [('abstract' | 'final')] [Class | Interface] class_name
[('extends' | 'implements')] [parent class Or interface name] {
// Method body
}
2. Method statement: good programming should minimize the coupling between classes and classes. The rule of thumb to follow is to limit the visibility of member functions as much as possible. If the member function does not need to be public, it is defined as protected; if it is not necessary, it is defined as private; the method definition syntax specification:
[Visibility] ['abstract'] ['static'] ['final'] ['synchronized'] [Return value type] method_name (parameter list) [('throws')] [Exception list] {
// Method body
}
Declaration order: construction method, static public method, static private method, public method, friend method, protected method, private method, main method; recommended order of method parameters: (being operated, operation content, operation flag, others).
3. Variable declaration: one statement per line; the simultaneous initialization of local variables (in the special case where the initial value of the variable depends on some previous calculations may not be initialized at the same time); only declare the variable at the beginning of the code block, ( A block refers to any code enclosed in braces "{" and "}"). Do not declare it when the variable is used for the first time; avoid declaring the local variable to overwrite the variable declared at the previous level, that is, not in the internal code The same variable name is declared in the block; public and protected visibility should be avoided as much as possible. All fields are recommended to be private and accessed by get and set member functions (Getter, Setter); do not include when defining a variable or constant Package name (similar to java.security.MessageDigest digest = null), unless two packages have the same class name; "[]" should be followed by the type instead of the field name when the array is declared; declaration order: constant, Class variables, instance variables, public fields, protected fields, friend fields, private fields.
Eight, abnormal
1. The purpose of catching an exception is to deal with it
. 2. Multiple exceptions should be caught and handled separately, avoid using a single catch to handle.
9. Habits
- No matter how many parts of the execution statement of if, for, do, while, etc., parentheses "{}"
- Whenever a case is executed down (because there is no break statement), you should usually add a comment at the position of the break statement;
- Try to avoid constructing and releasing objects in loops
- In the process of using local variables, handle according to the principle of proximity. It is not allowed to define a local variable, and then it is used only far away;
5. The same function is not allowed to be copied into N copies of code; - When processing String, try to use the StringBuffer class
Keep updating, so stay tuned! ! !
