Java Development specification summary_code annotation specification and java Annotation

Java Development specification summary_code annotation specification and java Annotation

It is a good habit to gradually develop codes.

1. Basic Rules

1. Annotations should make the code clearer and easier to understand
2. Annotations should be simple and clear, as long as the necessary information can be clearly understood. If the annotation is too complex, it means that the program needs to be modified and adjusted to make the design more reasonable.
3. Annotations not only describe what the program has done, but also describe why it is done and constraints.
4. Do not comment out the general getter and setter methods.
5. Annotations cannot be nested.
6. Compile the development document in Chinese.

2. Three annotations

1. document comments /***/

Multiple rows can be used to describe classes, interfaces, member methods, member variables, static fields, static methods, and constants. Javadoc can be used to generate code documents. For readability, indentation and format control are supported.
Document comments often use some tags to describe the specific purpose of a document. They are used to help Javadoc generate a document. Commonly used include:

Tag	Used	Purpose
@ Author name	Class/interface	Describe the author of the Code. Each author corresponds to a tag like this.
@ Deprecated	Class Member Method	This API has been abolished.
@ Exception name description Or @ Throws name description	Member Method	Exception thrown by the description method Each exception corresponds to one such tag.
@ Param name description	Member Method	Describes the purpose and meaning of a parameter in a member method. A parameter corresponds to a tag like this.
@ Return description	Member Method	Meaning of the returned value of the member Method
@ Since	Class/interface Member Method	The start time of the API segment.
@ See ClassName	Class/interface Member Method Member variables	Used to reference a specific class description. Generally, ClassName includes the full name of the package name.
@ See ClassName # memberfunction	Class/interface Member Method Member variables	It is used to reference the description of the member methods of a specific class. Generally, ClassName uses the full name including the package name.
@ Version text	Class/interface	Version
@ InheritDoc	Class/interface Member Method	Inherited document

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Line comment //

Only one line can be commented at a time. It is generally used to briefly describe a local variable. The role of the program block

3. Block comment :/**/

Forbidden in code

4. Class/interface comments

Class/interface description, generally more detailed. Sort by common instructions, including
1. Main description of the class,. Or. End
2. Category design goals and functions
3. <Strong> main class usage </Strong> how to use this class, including environment requirements, such as whether thread security, concurrency requirements, and use Constraints
4. <Strong> known bugs </Strong>
5. Description class modification history: <Strong> Modifier + date + simple description </Strong>
6. @ author, @ version, @ see reference, @ since start version, and other information such:

/** * This class provides default implementations for the JFC <code>Action</code>  * interface. Standard behaviors like the get and set methods for * <code>Action</code> object properties (icon, text, and enabled) are defined * here. The developer need only subclass this abstract class and * define the <code>actionPerformed</code> method.  * <p> * <strong>Warning:</strong> * Serialized objects of this class will not be compatible with  * future Swing releases.  The current serialization support is appropriate * for short term storage or RMI between applications running the same * version of Swing.  A future release of Swing will provide support for * long term persistence. * * @version 1.41 2015/05/26 * @author xxxxx * @see Action */

To make the written documents readable, the comments are often indented and formatted. The class description is placed before the class definition, and there cannot be any blank rows.

3. Variable comments

1. The member variables and static variables use document annotations. Comments to member variables generally include:
1) Significance of Variables
2) valid value range of a Variable
3) Restrictions on concurrent access
For example:

/*** UIAPP. xml initparam */public final static String APP_CONFIG = "aaa. uiapp" for configServlet parameters in the Web. xml file ";

2. Local variables, such as algorithm-related variables using block or line annotations

Public void func () {int I; // used for cyclic counting ............}

3. Parameter Variable annotations are generally described in the document and @ param is used as the parameter, which generally includes

1) Purpose of the Parameter

2) requirements on the parameter value range

4. Method Annotation

Describes functions of a function. For member methods and static methods, document descriptions are generally used, especially public methods. Annotations can be detailed. For readability or format control, the description below contains indentation:

/*** Here is a method comment with some very special* formatting that I want indent(1) to ignore.**/

Method annotations generally include:
1. The main description of the method is as follows. Or. End
2. describes the functions and objectives of a method, and the reasons for using this method.
3. Describe how to use the method, including the environment requirements for use, such as preconditions, post conditions, and concurrency requirements
4. Describe known bugs
5. Change History of the description method: <Strong> Modifier + date + simple description </Strong> (<Modifier + date + simple description>)
6. @ param c elements to be inserted into this list. (parameter description)
7. @ return <tt> true </tt> if this list changed as a result of the call. (return value description)
8. @ throws NullPointerException if the specified Collection is null. (exception description)
9. @ see if you want to overload a method, you must refer to the method of the parent class.
Using Alt + Shift + J to generate Javadoc for 10 Gb/s indicates the return value of the method (@ return)

5. Modify records

1. Before modifying a class, you must update it from SVN before modifying it;
2. comments must be added to the modified location to describe the author, reason, content, and time of modification;