I. The significance of coding norms
The application coding specification is particularly important for the software itself and for software developers for several reasons:
1) A good coding specification can reduce the maintenance cost of a software as much as possible, and almost no software is maintained by the original developer throughout its life cycle;
2) Good coding standards can improve the readability of the software, allowing developers to quickly and thoroughly understand the new code;
3) Good coding standards can maximize the cooperation efficiency of team development;
4) long-term normative code can also allow developers to develop good coding habits, and even exercise more rigorous thinking;
II. specification of specific nomenclature
1, the meaning of identifiers
2) Adoption of terminology applicable to related fields
3) Use a mixed case to make the name readable
4) Minimize the use of abbreviations, but if used, must conform to the entire project in a unified definition
5) Avoid using a long name (less than 15 letters for normal selection)
6) Avoid using a similar name, or just a different name or case
7) Avoid using underscores (except static constants, etc.)
2. Identifier type description
1) naming of packages (package)
the package name should be in full English descriptors, which are made up of a lowercase word. and the package name prefix is always a top-level domain name, usually com,edu,gov,mil,net,org, etc.;
such as: com.yjhmily.test
2) Naming of classes (class)
The class name should be a noun, in a mixed case, capitalized by the first letter of each word. Try to ensure that the class name is concise and rich in description. Use full words to avoid abbreviations (unless the project has a uniform abbreviation specification or the abbreviation is more widely used, like URLs, HTML)
such as: filedescription
3) name of the interface (Interface)
similar to the naming conventions of class. On the basis of satisfying the CLASSD naming rules, the first letter "I" is guaranteed, which is easy to distinguish from normal class. Its implementation class name takes the second letter of the interface name to the last, and satisfies the naming specification of the class name;
such as: imenuengine
4) enumeration ( enum) naming
similar to the naming conventions of class. On the basis of satisfying the CLASSD naming rules, the first letter "E" is guaranteed, which is easy to distinguish from normal class.
such as: euserrole
5) Naming of exceptions (Exception)
exceptions ( Exception) typically use the letter e to indicate an exception, and for a custom exception class, the suffix must be Exception
such as: businessexception
6) Naming of methods (method)
The method name is a verb, in mixed case, the first letter in lowercase, followed by the first letter of the word capital. The method name describes the action behavior of the method as much as possible. A method that returns a Boolean of type is typically preceded by "is " or "has"
such as: Getcurrentuser (), addUser (), hasauthority ()
7) name of the parameter (Param)
The first letter is lowercase, followed by the first letter of the word. The parameter number name does not allow an underscore or dollar sign to start, although this is syntactically permissible. Parameter names should be short and descriptive.
such as: Public UserContext Getloginuser (String loginName);
8) Constant field ( Constants ) is named
Static constants fields (static final) are all uppercase letters, and the words are separated by underscores;
such as: public static final Long FEEDBACK;
public static Long User_status;
Third, the annotation specification
1. Meaning of annotations
1) Comments should increase the clarity of the code
2) Keep the annotations simple
3) write comments before or at the same time
4) Comment out why something has been done, not just what has been done
2. Note which parts
1)Java file: You must specify the copyright information and the creation time and author of the file;
2) Class: The purpose of the class, the function completed by the class, and the time and author name created by the class; When multiple people edit or modify the same class at a time, multiple names should appear at the author's name;
3Interface: On the basis of satisfying class annotations, the interface annotations should include the purpose of setting up the interface, how it should be used, and how it should be used. The corresponding implementation class can be annotated without the explicit interface annotations;
4) Method Note: For settings(Set method) and get(Get method) Member's method, which can be commented out without comment, if the member variable is already described, the ordinary member method requires a description of what is done, what the parameter means and what the return value is, and the creation time of the method must be clearly annotated to provide valuable clues for future maintenance and reading;
5Method Internal comments: Control structure, what the code does and why, the processing order, especially the complex logic processing part, to give as much as possible to the detailed comments;
6) Parameters: Parameter meaning, and any other constraints or preconditions;
7) attribute: Description of the field;
8Local (middle ) variable: Without special meaning, no comment;
3. Note format
Follow the uniform annotation format of the engineering rules, typically importing files in codetemplates.xml format into the IDE (Eclipse) or by default with Eclipse;
Four, code format specification
Follow the Uniform code format specified in the project, and generally use the IDE (Eclipse) directly Formats the code with the default code format that comes with it;
1 separate line Comment: A single line of comments in the code, preferably a line before the comment, and has the same indentation level as the code behind it. If a single line cannot be completed, the block comment should be used.
Annotation format: /* Note content */
costume note: Comment At the beginning of the line of code. Primarily to make the line code meaningless.
Annotation format: // comment content
end note: End (trailing)-a very short comment, commented at the end of the line of code. Typically with a line of code after 8 (at least 4) of the grid, all comments must be aligned.
Comment Format: Code + 8 (at least 4) spaces +//comment content
2, block--block comment: /*......*/
comment on several lines, usually to provide a description of the meaning and purpose of a file, method, data structure, and so on, or an algorithm. Usually located in the front of a file or a method, play the role of guidance, you can also be placed in the appropriate position as needed. This domain comment does not appear in the HTML report. Note formats are usually written as:
/*
* Comment Content
*/
3. Document Comment:/**......*/
Comment on several lines and write to the Javadoc document. Each document comment is placed in the comment delimiter /**......*/, and the comment document is used to generate the HTML-formatted code report, so the comment document must be written before the class, domain, constructor, method, and field definition. A note document consists of two parts-a description, a block tag. Note The format of the document is as follows:
/**
< Span style= "FONT-SIZE:14PX;" > * note content
*/
Java Programming Specification