Java coding specifications that you should read before coding

Java coding specifications 1.1 why coding standards are especially important for programmers, there are several reasons: 80% of the cost of a software life cycle is maintenance. Almost no software is maintained by the original developer throughout its lifecycle. Coding specifications can improve the readability of software and allow programmers to understand new code as soon as possible.

If you release the source code as a product, you need to ensure that it is well packaged and clear, just like any other product you have built. In order to implement the specification, each software developer must comply with the encoding specification. Everyone !!! 1.2 copyright notice this document reflects the coding standard section in the Java language specification of Sun MicroSystems. Major contributors include Peter King, Patrick Naughton, Mike DeMoney, Jonni Kanerva, Kathy Walrath, and Scott Hommel. This document is now maintained by Scott Hommel. for comments, please send to the shommel@eng.sun.com 2. File Names Section listing commonly used File Names and their suffixes. 2.1 File Suffixes Java programs use the following File Suffixes:

File class file suffix Java source file. java
Java bytecode file. class
2.2 Common File Names)
Common file names include:

Object Name Purpose

The preferred file name for GNUmakefile makefiles. We use gnumake to create (build) software. README outlines the preferred File name for a File containing content in a specific directory 3. File Organization a File consists of paragraphs separated by blank lines and Optional comments that identify each paragraph. Programs with more than 2000 rows are hard to read and should be avoided as much as possible. The "Java source file example" provides a Java program example with a reasonable layout. 3.1 Java Source Files each 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 and public classes in the same source file. The public class must be the first class or interface in this file. Java source files also follow the following rules: Start comments (see "Start comments ")
Package and Import Statement (see "package and Import Statement ")
Class and interface declaration (see "class and interface declaration") 3.1.1 start with Comments (Beginning Comments). All source files should have a c-language style comment at the Beginning, lists the class name, version information, date, and copyright statement :/*
* Classname
*
* Version information
*
* Date
*
* Copyright notice
*/3.1.2 Package and Import Statement (Package and Import Statements)
In most Java source files, the first non-Comments line is a package statement. After that, you can introduce the statement. For example:
Package java. awt;
Import java. awt. peer. CanvasPeer; 3.1.3 Class and Interface declaration The following table describes the parts of the Class and Interface declaration and their order of appearance. See an example with annotations in the "Java source file example.

Annotation of each part of the class/interface declaration 1. annotation of the class/interface document (/**...... */) The information to be included in the comment. For more information, see "document comment"

2. Declaration of classes or interfaces

3. Comments for class/interface implementation (/*...... */) If necessary, the comment should contain any information about the entire class or interface, which is not suitable for commenting on the class/interface document.

4. The class (static) variables are first the class public variables, followed by the protection variables, and then the package-level variables (no access modifier, access modifier ), the last is the private variable.

5. The instance variables are at the public level, followed by the protection level, followed by the package level (no access modifier), and finally the private level.

6. constructor 7. methods should be grouped by functions rather than scope or access permissions. For example, a private class method can be placed between two public instance methods. The purpose is to facilitate reading and understanding the code.

4. Indentation four spaces are often used as a unit of Indentation. The exact description of indentation is not specified in detail (space vs. Tab ). A tab is equal to eight spaces (not four ). Line Length: avoid a Line with more than 80 characters, because many terminals and tools cannot handle it well. Note: The example used in the document should use a shorter length, which generally cannot exceed 70 characters. 4.2 Wrapping Lines when an expression cannot be contained in a row, it can be broken according to the following general rules. Disconnect before an operator. Rather than higher-level disconnections. The new line should be aligned with the beginning of the expression of the previous line at the same level. If the above rules cause your code to be chaotic or make your code pile up on the right side, place it with eight spaces. Some examples of method call disconnection are as follows: someMethod (longExpression1, longExpression2, longExpression3,
LongExpression4, longExpression5 );
Var = someMethod1 (longExpression1,
SomeMethod2 (longExpression2,
LongExpression3); The following is an example of two disconnected arithmetic expressions. The former is better, because the disconnection is located outside the bracket expression, which is a higher level of disconnection. LongName1 = longName2 * (longName3 + longName4-longName5)
+ 4 * longname6; // PREFFER
LongName1 = longName2 * (longName3 + longName4
-LongName5) + 4 * longname6; // AVOID the following is an example of two indent method declarations. The former is a general situation. If the latter uses the regular indent method, it will move the second and third rows to the right, so it will be indented with 8 spaces // CONVENTIONAL INDENTATION
SomeMethod (int anArg, Object anotherArg, String yetAnotherArg,
Object andStillAnother ){
...
} // INDENT 8 SPACES TO AVOID VERY DEEP INDENTS
Private static synchronized horkingLongMethodName (int anArg,
Object anotherArg, String yetAnotherArg,
Object andStillAnother ){
...
}

The line feed of if Statements usually uses eight spaces, because regular indentation (4 spaces) makes the statement body look hard. For example: // DON't USE THIS INDENTATION
If (condition1 & condition2)
| (Condition3 & condition4)
|! (Condition5 & condition6) {// BAD WRAPS
DoSomethingAboutIt (); // MAKE THIS LINE EASY TO MISS
} // USE THIS INDENTATION INSTEAD
If (condition1 & condition2)
| (Condition3 & condition4)
|! (Condition5 & condition6 )){
DoSomethingAboutIt ();
} // OR USE THIS
If (condition1 & condition2) | (condition3 & condition4)
|! (Condition5 & condition6 )){
DoSomethingAboutIt ();
}

There are three feasible methods for processing the ternary expression: alpha = (aLongBooleanExpression )? Beta: gamma;
Alpha = (aLongBooleanExpression )? Beta
: Gamma;
Alpha = (aLongBooleanExpression)
? Beta
: Gamma; 5. Comments Java program has two types of Annotations: implementation comments and document comments ). Implementation annotations are those that have been seen in C ++ and are defined using/*... */and. Document comments (known as "doc comments") are unique to Java and are defined. You can use javadoc to convert document comments into HTML files. Implementation annotations are used to annotate code or implementation details. Document comments describe code specifications from the perspective of implementation-free. It can be understood by developers who have no source code at hand. Annotations should be used to give a summary of the Code and provide additional information that the Code itself does not provide. Annotations should only contain information related to reading and understanding programs. For example, information such as how the corresponding package is created or in which directory should not be included in the comment. In comments, it is okay to describe the important or not obvious aspects of design decisions, but avoid providing repeated information clearly expressed in the code. Additional comments are easily outdated. Generally, comments that may be out of date due to code updates should be avoided.
Note: frequent comments sometimes reflect the low quality of the Code. When you feel forced to add comments, consider rewriting the Code to make it clearer. Comments should not be written in a large box drawn with asterisks or other characters. Comments should not contain special characters such as tabs and rollbacks. 5.1 The Implementation Comment Formats program can have four annotation styles: block, single-line, and trailing) and end-of-line ). 5.1.1 Block Comments are usually used to provide descriptions of files, methods, data structures, and algorithms. Block annotations are placed at the beginning of each file and before each method. They can also be used in other places, such as internal methods. Block comments inside functions and methods should have the same indent format as the code they describe. There should be a blank line at the beginning of the block comment, which is used to separate the block comment from the code, for example :/*
* Here is a block comment.
* The Block comment can start with/*-, so that indent (1) can recognize it as the beginning of a code block without shuffling it. /*-
* Here is a block comment with some very special
* Formatting that I want indent (1) to ignore.
*
* One
* Two
* Three
*/

Note: if you do not use indent (1), you do not need to use/*-in the Code, or make concessions for others to run indent (1) on your code.

Author: "Chen yanzhi's blog"