These Java code development specifications, read everyone good!

As a developer, when you’re working on someone else’s project and you’re reading someone else’s code, do you ever feel like your head is bleeding and Java is sending you “away”? We must adhere to the Java development standards before using Java development technology development, only then you will have a smoother Java development path. And master the corresponding Java development skills, you can get twice the result with half the effort.

I. Layout specification:

1. Add a space between the keyword (or variable) and the operator. For example, int iCont = 1; // There is a space between the operator and the value.

2. Add empty lines between blocks of relatively independent code. For example, two methods must be separated by a space.

3. Longer statements, expressions, etc. should be written in multiple lines.

4. Long expressions partition new lines at the lower-priority operator, which is placed at the head of the new line.

5. The new line of code is indented logically (a table key) from the previous line to make typography neat and sentences easy to read.

6. It is not allowed to write multiple phrases on a single line, that is, write only one statement on one line.

7. Indent the code in statements such as the start of a function or procedure, the definition and loop of a structure, and judgments. Use the TABLE key to indent.

8. If there is a long expression or statement in a loop or judgment statement, it should be adapted to the division.

9. If the parameters of a function or procedure are long, partition them appropriately.

10. When delimiting a block with braces’ {‘ and ‘}’, the blocks’ {‘ and ‘}’ should be written on a single line and in the same column, aligned left with the statements that reference them. The above indentation is used at the beginning of the function body, in the definition of classes, structures, enumerations, and in the if, for, do, while, switch, and case statements.

JAVA Code Development Specification (WISHSOFT)

1. Main method: If the main(String[]) method is already defined, it should be written at the bottom of the class.

Ii. Naming conventions:

1. Naming the Package

The name of the Package should all consist of one lowercase word. For example: package com. Wish;

2. The naming of the Class

The name of the Class must consist of words that begin with a capital letter and all other letters are lowercase, for all identifiers, the

All the words contained in the text should be placed next to each other and capitalized. Such as:

public class DatabaseOperator { }

The name of a variable must start with a lowercase letter, followed by an uppercase letter, and does not require a data type prefix. For example, the userName, the size.

4. Name Static Final variables in Class

The names of static Final variables should be capitalized and indicate their full meaning.

Such as:

public static final String DB_CONFIG_FILE_PATH =”com.neu.etrain.dbconfig”;

The name of a method must begin with a lowercase letter and the following words must begin with an uppercase letter. For example, setName(), getMethod().

6. Use meaningful parameter names in method declarations, and if possible, use the same name as the field to which you are assigning. Such as:

public void setCounter(int size) {

JAVA Code Development Specification (WISHSOFT)

this.size = size;

}

7. Naming of variables within a method

The naming of member variables in Class.

8. Array naming

Arrays should always be named byte[] buffer; Instead of: byte buffer[];

9. Use pageSize for the number of lists per page. The current pageNumber is pageNumber.

Iii. Annotation Specification:

1. Keep your comments simple.

2. Comments while writing the code, modify the code and modify the corresponding comments to ensure the consistency of the comments and the code.

3. Make moderate notes where necessary. The content of annotations should be clear and clear, with accurate meaning to prevent ambiguity in annotations. Keeping comments adjacent to the code they describe is the proximity rule for comments.

4. Comments on variables and constants should be placed above or to the right, not below.

5. Global variables should have more detailed annotations, including the function, value range, which functions or procedures to access it, and precautions when storing.

6. Annotation of classes and methods is automatically generated by Eclipse.

When the declaration of a class or method is complete, the system will automatically generate their annotation template after typing :/** in the English input method state (no space), we just need to fill in the corresponding text, note :/** next line must write function description.

7. Description of specific requirements:

N Declarative (variable definition class) must have comments. For example: String myName. // User name n class definitions must generate documentation (JavaDoc) annotations.

N methods must generate documentation (JavaDoc) annotations (including set, get methods of entity classes). N Member variables must generate documentation (JavaDoc) comments.

N The logic part of the method is written by the programmer according to the complexity.

8. Comment information for the class definition, including: author; Date; Module function description (such as function, main algorithm, internal parts

The relationship between, the document and other documents, etc.); Historical modification records of this document; Version information.

/ * *

* What is it for (Description)

JAVA Code Development Specification (WISHSOFT)

*@author lifw20080320

*@modify lifw20080321

*@modify lifw20080322 (if there are multiple, write multiple @modify) * @copyright wishsoft **/

Javadoc comment tag syntax

The @author description of the class identifies the author who developed the module

The @version description of a class indicates the version of the module in that class

@see description of classes, properties, and methods Reference direction, that is, the related topic @param description of methods description of a method parameter

@return Description of a method Description of the return value of a method

@exception Specifies the exception that the other method may throw

4. Basic datatype prefix table (other object types, supplement at any time):

5. Method writing specification

1. For member methods, do not easily use public member variables. The main modifiers are public, private, protected, and none

2. In an empty method, the method declaration and the function body can be on one line. Such as: void func () {}

3. There is a blank line between methods

4. The documentation comment of the method should be placed immediately before the method, without a blank line.

5. Avoid too many parameter lists and try to control them within 5. If multiple parameters need to be passed, an object containing these parameters should be used to pass them to improve the readability and expansibility of the program

6. The circulating hidden sleeve in the method shall not exceed 2 layers

7. Use final whenever possible for classes that do not require subclasses to reload at design time

8. Try not to exceed 100 lines of code per method (valid lines, not including comments), but ensure logical integrity

9. The default level of methods in interfaces is protected, and methods are only exposed to public if you are sure that packages from other subsystems will call methods in their interfaces.

Vi. Language use and writing standards

1. Avoid defining variables with the same name as variables in the upper scope.

2. Separate methods with an empty line

3. Local variables are declared at the time of use, and local/static variables are initialized at the same time

4. The number often precedes the comparison expression when compared with a constant:

if(" simpleCase. "equals (obj))...if(null = = obj... .copy codeCopy the code

5. Do not have complex operations in return statements.

6. Switch statement, which requires a default branch

Write at the end:

That’s the end of this article! If there are any mistakes in this article, please comment, appreciate!