"Java" Java Coding specification __java

Personal integration of some common development norms, for reference only.

The source code file encoding should be UTF-8.

Any character that needs to escape the string representation (such as \b, \ t, \ n, \f, \ r, \, \ etc) is represented by this escape string.

The top portion of the entire source file should have the following four pieces, separated by a blank line between each section . 1.License or Copyright declaration information . 2. Package declaration statement, and package declaration has no length limit , single line length limit specification, not applicable to package declaration. 3.import statements and should not use the wildcard import. All static imports are a set of non-static imports as a group. If both static and non-static imports exist, they are separated by a blank row. The 4.class class declares that there can be only one top-level classin each source file. class member order should be logical. When a class has multiple constructors or multiple methods with the same name, the function is written in some, with no other code in the middle.

The

format specification above, can be integrated into the format. The specification for the statement block is as follows. 1. No wrapping before curly braces. 2. After opening curly braces, wrap. 3. Wrapping before closing curly braces. 4. If the closing bracket ends with a statement block or function body, constructor body, or named class body, you need to wrap the line. For example, when an else or a comma is followed by a closing parenthesis, the line should not be wrapped. 5. An empty statement block that can really connect to the closing brace after the opening of the brace, with no spaces or lines to wrap in the middle. However, when a statement block that consists of several statement blocks is combined, a line wrap is required. (For example: If/else or try/catch/finally) 6. For indentation of a statement block, indents add two spaces whenever a new statement block is generated. When the statement block ends, the indents back to the number of indents on the previous level . Indentation requirements apply to both the code and the annotations in the entire statement block. 7. The end of each line of code requires line wrapping . The 8.Java code has a single line limit length of 100 characters . Lines that exceed this limit must be wrapped except for the following conditions. Set "line wrapping" to modify the value of the "Maximum line width" below it. 9. When the line breaks, after the first row, we call the continuation line. Each continuation row indents at least four characters based on the first row. indents can be greater than 4 characters when there are more than one continuation row after the original row. If multiple continuation lines break by the same syntax element, they can take the same indentation. -

For the horizontal whitespace of the code, there is a situation like the following. 1. All reserved keywords need to be separated from the left parenthesis immediately following it in the same line. (For example,for,catch) 2. All reserved keywords need to be separated from the right curly braces before it. (For example else,catch) 3. After commas, colons, semicolons, and closing parentheses, spaces are required . 4.//when a double slash begins a line of comments. Double slash both sides should be separated by a space. You can use more than one space, but do not make a mandatory request. 5. Variable declaration, the variable type and variable names need to be separated by a space. 6. When initializing an array, the curly braces can be separated by spaces or not used. (For example: New int[] {5, 6} and new int[] { 5, 6 } can be)

For variable processing, like the case. 1. Do not use a declaration to declare multiple variables . For example int A, b;. 2. Local variables should not habitually be declared at the beginning of the statement block, but should be as far away as possible from the nearest local declaration where it was first used, to reduce their scope of use . 3. Local variables should be initialized at the time of declaration. If you cannot initialize at the time of declaration, you should also complete initialization as soon as possible .

Multiline comments, if you want the integrated development environment to automatically align annotations , you should use/**/,//generally not align automatically.

A Long value integer constant uses the uppercase L suffix and never has lowercase (avoid confusion with the number 1). For example: 3000000000L rather than 3000000000l.

to name the related specification. 1. package name All in lowercase letter , passed. Connect the levels together. Underline should not be used. such as Com.example.deepspace. 2. Name of type, using the uppercase and lowercase character spacing at the beginning of the uppercase letters (uppercamelcase). To name a test class, start with the name of the class it tests, and then at End with Test . For example: Hashtest, Hashintegrationtest. 3. Method names generally use verbs or verb phrases, in the form of uppercase and lowercase letters spaced at the beginning of a small letter (lowercamelcase). 4. In JUnit's test methods, you can use underline to differentiate the name of the test logic, often using the following structure: Test_. For example: Testpop_emptystack. 5. Constants are generally named with nouns or noun phrases. All use uppercase characters , and the word is separated from the word by an underline . (Constance_case). 6. The extraordinary amount of member variable name (including static and non-static variables), using Lowercamelcase name. Use nouns or noun phrases in general. 7. The name of the parameter is named by Lowercamelcase. You should avoid using one character, and so on as a naming method for parameters. 8. Local variables are named by Lowercamelcase. It can take a shorter, looser approach than other types of naming. 9. Even if the local variable is final and immutable, it cannot be considered a constant, nor should it be named by a constant name. 10. Type names can be named in two ways: one is a single capital letter, sometimes followed by a number. (for example, E, T, X, T2). Two. Like a generic class name (see 5.2.2), then the last uppercase letter . (for example, Requestt, Foobart).

Best practices. 1. Package names are all in lowercase letters, passed. Connect the levels together. Underline should not be used. such as Com.example.deepspace. 2. In general, catch-live exceptions should not be overlooked, but should be handled appropriately. For example, if you print the error log, or if you think this exception does not occur, you should throw it back as an assertion exception. If this catch-live exception does not require any processing, it should also be explained by annotations. 3. When a static member is accessed, it should be accessed through the class name, rather than using the specific instance object of this class. 4. Use as little as possible without even using the Finalizers method.

For Javadoc. 1. General format for annotations: When Javadoc blocks have only one row, you can use single-line formatting instead of the common format. 2. Blank line: Refers to Javadoc, the top and bottom two paragraphs between the top and bottom of the * * Characters of the line. The first line of each paragraph has a label before the first character, and there is no space after that. 3.@ clause: All standard @ clauses should be added in the following order: @param, @return, @throws, @deprecated. And these four @ clauses should not appear in a Javadoc block that is not described. You should break the line when the @ clause cannot be finished in one row. The continuation line indents at least 4 character units at the position of the @ character in the first line. 4. Summary fragment: The main summary is only a fragment, should be a noun phrase or a verb phrase, not a complete sentence. But it should use punctuation like a complete sentence. A common mistake is to use the javadoc:/* @return the customer ID/in this form. That's not right. should read:/* Returns the customer ID. /。

For where Javadoc is not used. 1. When the method itself is obvious, Javadoc is not required. For example: Getfoo. There is no need to add Javadoc to the description "Returns the foo". 2. Overloaded methods sometimes do not need to write Javadoc. 3. Some class and member variables or methods that are not visible outside the package can also be used for Javadoc as needed. 4. When an annotation is used to describe the overall goal or behavior of the class, variable, or method, the annotation should use Javadoc (using/**)