JAVA language programming format advanced specification

As a developer, you need to have strict code specifications. I've summarized some code specification cases for this.

Orders to record

1. Introduction

2. Trial range

3. JAVA naming specification --

3.1 public agreement

3.2 Java files and packages

3.3 naming conventions for classes and interfaces

3.4 method naming conventions

3.5 constant

3.6 variables and parameters

3.7 components/parts

3.8 the collection

3.9 mysterious Numbers

3.10 other

3.11 Java exception

3.12 array naming

3.13 database table naming rules

3.14 database field naming rules

3.15 name the JSP file

3.16 Servlet class naming

4. Standard writing style

4.1 the indentation

4.2 the blank space

4.3 the alignment

4.4 a blank line

4.5 annotations

5. Code file style

In order to ensure the readability of the system source program and enhance the maintainability of the system, the following programming specifications are formulated to standardize the programming of all parts of the system. Source programs in other resources that the system inherits should also be modified according to this specification.
This document will be a programming format specification developed by hebei post application system software (JAVA language). In the system coding, testing and maintenance process, strict compliance.
3. JAVA naming specification
3.1 public agreement  Naming refers to the system name of the source file name, method, directory, package, database table name, database field, and so on. The & # 61656;
All the names used in the system are expressed in English abbreviations. The & # 61656;
The method of naming is: prefix +{abbreviation of naming morpheme}, the prefix expresses the purpose of naming, such as database table, etc. The & # 61656;
The named prefix is determined by the project team. The & # 61656;
Name all objects in lowercase except the system common maintenance objects. One way is to use "_" as a conjunction, the other way is to capitalize the first letter of a morpheme directly together. In this specification, the database name, database field name in the first way, the rest of the second way. The & # 61656;
Use full English descriptors that accurately describe variables/fields/classes/interfaces/packages, etc. For example, using names like firstName, listAllUsers or CorporateCustomer, the use of pinyin and unrelated word names is strictly prohibited. Although Java supports Unicode naming, this specification stipulates that packages, classes, interfaces, methods, variables, fields, etc., shall not be named using Chinese characters .
Use case mixing to improve the readability of names. Generally lowercase letters should be used, but the first letter of the name of the class and interface, and the first letter of any intermediate word should be capitalized. Package names are all lowercase. The & # 61656;
Use abbreviations sparingly, but if necessary, use public abbreviations and customary abbreviations, e.g., implement may be abbreviated as impl, manager may be abbreviated as MGR, etc. Please refer to the table below for details. The & # 61656; Avoid long names (preferably no more than 25 letters).

Avoid Numbers, but use 2 instead of to, 4 instead of for, etc., such as go2Jsp.

3.2 Java files, packages 
When the filename is exactly the same as its class, all words begin with uppercase. The & # 61656;
Package names are generally named after project or module names, with fewer abbreviations and long names and all lowercase. The & # 61656;
Basic package: com.czpost. All packages and files are subordinate to this package.
The package name is composed of the following rules: [base package].[project name].[module name].[submodule name]... Such as: com. Czpost. Eims com. Hepost. Eims. Until the & # 8222; The & # 61656;
Classes must not be defined directly under the base package. Classes, interfaces, and so on in all projects should be defined in their own project and module packages.

3.3 naming specification of class and interface  All words are capitalized. Use words that accurately reflect the class, interface meaning, functionality, and so on. Nouns are generally used. The & # 61656;
An interface may have an I prefix or suffixes such as able, ible, er.

3.4 method naming conventions methods should be named with a full English descriptor, mixed case: capitalize the first letter of all middle words. The first word of a French name often takes a verb with a strong action color. The value class USES the get prefix, the set class USES the set prefix, and the class USES the is(has) prefix. GetName () setSarry() isLogon() method parameters suggested order: (by the operator, operation content, operation flag, others ⋯) Example: public void replace(String sourceStr, String oldStr, String newStr) {... }

3.5 constants use full uppercase English words, with an underscore between words, such as DEFAULT_VALUE

3.6 it is suggested to adopt Hungarian nomenclature for variables and parametric variables. For morpheme rules, see "common convention" & # 61692.
Integer variables (including int, short, long) : beginning with n, e.g. long nCredNum; The & # 61692;
Floating point variables (including float, double) : start with an f, for example: double fTranAmt; The & # 61692;
Character variables: start with c, for example: char cPageFlag; The & # 61692;
Date-type variables: start with d, for example: date dToday; The & # 61692; Boolean variable: begins with is, for example, Boolean isFlag; The & # 61692;
String variable: begins with s, for example: char sPageNo[2+1]; The & # 61692;
Global variable: combines the type of data beginning with g, for example: char gsBankNo[10+1]; The & # 61692;
Static variables: static variables in the file is also a global variable, the naming rules and global variables. The & # 61692;
System-level variables: system-level variables are also global variables, starting with '_' in combination with the type of data.
For example: char _sBankNo[10+1] has no 'g'.
Temporary variables are usually named I, j, k, m, and n, and they are used for integers; C, d, e, they are generally used for character types.

3.7 components/parts should be named components (interface parts) in full English descriptor, following Hungarian naming rules such as btnOK, lblName. The & # 61692; Button variables BTN +Xxxxxxx such as: btnSave, BTN Exit, btnPrint  LBL +Xxxxxxxx for example: lblName, lblSex and other object type prefix Canvas CVS CheckBox CHK Image img List LST Choice CHC Dialog DLG Event evt Frame FRM Menu Panel PNL TextArea txa TextField TXF

A collection, such as arrays and vectors, should have complex names to represent the types of objects in the queue. Full English descriptors should be used for naming, the first letter of all non-beginning words in the name should be capitalized, and the collection abbreviation prefix should be used where appropriate. For example: Vector vProducts = new Vector(); // product vector Array aryUsers = new Array(); // list of users

3.9 mysterious number programs often use some quantity, it has a specific meaning, the mysterious number is defined as a constant. Note that the name of the constant should express the meaning of the number and should be capitalized to distinguish it from the identifier corresponding to the variable. For example, the number 50 can be defined as a constant named NUM_OF_EMPLOYEES instead.

3.10 other names should be expressed using complex Numbers to represent multiple values. Such as: the orderItems.

3.11 the Java Exception Exception class name consists of the words that represent the Exception type and Exception, such as ActionException.
Exception instances typically use e, ex, etc., and are composed of the exception name or shorthand for multiple exceptions plus e, ex, etc., such as SQLEx ActionEx

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

3.13 database table naming rules  The prefix and the nominal morpheme are separated by an underscore. The & # 61692; Names are made up of lowercase letters. The & # 61692;
If the nominal morpheme is composed of a single word, it can be spelled in full. If it's multi-word, use abbreviations. Abbreviations are underlined. For example: the & # 61656; Library table: starts with 't_'  View: begins with 'v_'  Library table index: starts with 't_' and ends with' _idx'  Library table unique index: starts with 't_' and ends with' _uidx'

3.14 database field naming rules 
If the nominal morpheme is composed of a single word, it can be spelled in full. If it's multi-word, use abbreviations. Abbreviations are underlined. The & # 61692; Names are made up of lowercase letters. The & # 61692; No prefix.

3.15 the JSP file name is a complete English description of what the JSP does, including, if possible, a vivid verb with the first letter in lowercase, such as: viewmessage.jsp, edituser.jsp, or forumchooser.jsp.

3.16 the name of Servlet class generally corresponds to the suffix Service for the object served, such as: UserService, TradeService, etc.

4. Writing format specification strict requirements of writing format is to make the program neat and beautiful, easy to read, unified style, programmers should have a clear understanding of the necessity of standard writing. It is recommended that the source program be developed using eclipse tools, and that the format specification be pre-set in the tool.

4.1 indentation is recommended to be in units of 4 Spaces. Preprocessing statement, global data, title, caption, function description, label, etc. The "{", "}" of the statement block is matched and aligned, and aligned with the previous line. The indentation of the statement block class suggests that each "{", "}" takes a separate line for the convenience of matching. The default in sclipse is to start with "{" instead of a single line.

4.2 whitespace in principle variables, classes, constant data, and functions in their types, modify the name between the appropriate space and according to the case alignment. A space above the keyword principle, such as: if (... ), etc. The operator Spaces are specified as follows :" :", "->" , "[", "]", "++", "--", "~", "!" , "+", "-" (positive and negative), "&" (quote), and other operators without a space (where the monocular operator refers to the side connected with the operand), other operators (including most binary and ternary operators "? "Add a space to both sides. If you define a function, you can align it with more space or no space. "," the operator is only one space empty after it, and may not be empty or more Spaces if it needs to be aligned. Use appropriate Spaces to separate and align comments after lines of statements, whether or not there are parentheses. I think this can be decided according to personal habits to follow or not.

4.3 alignment in principle, closely related lines should be aligned, including type, decoration, name, parameters, and other parts of the alignment. The length of each line should not exceed the screen too much, when necessary, appropriate line break, line break as far as possible at the "," or the operator, after the line break is best to start with the operator, and the following lines are indent with the first line of the statement, but the statement is still indent with the first line, that is, the next behavior "{" should be aligned with the first line. Variable definitions are best aligned by adding Spaces or tabs, and variables of the same type are best placed together. As shown in the following example: int nValue; Int nResult; Int nLength;

4.4 a blank line must not have an irregular blank line, such as ten blank lines in a row. The program file structure between the parts of the empty line, because each function also has a function description comments, so usually only empty line or not empty, but in the case of no function description should be at least one line. For the function you write, add "//--" as a separator. There should be at least one line between the data inside the function and the code, and an empty line in the code where appropriate. It is recommended that when a variable declaration appears in the code, it should be preceded by an empty line. There should be at least one blank line between the four "ps" in the class and between the data and the function in it.

4.5 comments comments are the concrete embodiment of software readability. The amount of program annotation generally accounts for 20% of the amount of program coding, and software engineering requires no less than 20%. Program comments should not be used in an abstract language, such as "processing", "loop" such as the computer abstract language, to accurately express the processing instructions of the program. Instead of using comments for every line of code, you can prefix a section of code with comments that have clear processing logic. Comments are essential, but should not be excessive. Do not passively write comments for the sake of writing them. Here are four necessary comments:  Title, additional instructions. The & # 61692; Description of functions, classes, etc. Proper instructions to almost every function, usually before the function, in the case of part didn't have a function is added before the function prototype, its content is primarily a function of function, purpose, algorithm, parameters description, return value, etc., need to have some instructions such as special hardware and software requirements. Declarations of public functions and classes must be annotated to explain how they are used and how they are designed, but choosing the right naming format can help you explain things more clearly. The & # 61692;
There must be some clarification where the code is unclear or not portable. The & # 61692;
And a few other comments, such as comments for custom variables, code writing time, and so on.

All Java(*. Java) files must follow the following style rules: 
File generation for the specification of JAVA derived classes, use eclipse tools to generate file formats whenever possible, and avoid manual header/implementation files. The & # 61692; The package/import package line should precede the import line, and the standard package names in import should precede the local package names and be arranged alphabetically. If the import line contains different subdirectories in the same package, it should be handled with *.
Package hotlava.net.stats; Import the Java. IO. *; Import the Java. Util. Observables. The import hotlava. Util. Application; Here java.io.* is used instead of InputStream and OutputStream. The & # 61692;
File header comments file header comments are mainly to indicate some information about the file, is the overall description of the program, can enhance the readability and maintainability of the program. The file header comment typically follows the package/imports statement and precedes the Class description. Write out at least the file name, creator, creation time, and description of the content. The format should be as restrictive as possible:  Class is followed by the Class comment, which is generally used to explain the Class. Next is the class definition, which contains extends and implements public class CounterSet extends Observable implements Cloneable  on different rows; The Class Fields

Next is the member variable of the class: protected int[] packets; The member variable of public must generate the document (JavaDoc). Member variables defined by proceted, private, and package can be uncommented if their names are unambiguous. The & # 61692; Access methods are followed by methods that access class variables. It's simply used to assign a variable to a class to get a value, and it's simply written on one line. (I think as much as possible to write the branch)

public int[] getPackets() { 
 
return copyArray(packets, offset); 
 
} public int[] getBytes() { 
 
 return copyArray(bytes, offset); 
 
} 
 
public int[] getPackets() { 
 
 return packets; 
 
} public void setPackets(int[] packets) { 
 
this.packets = packets; 
 
} 

Don't write the other methods on one line. The constructor is followed by the constructor, which should be written incrementally (e.g., with more arguments at the end). Access types ("public","private", etc.) and any "static","final", or "synchronized" should be on one line, and methods and arguments should be written on another line to make them more readable.

Public CounterSet (int size) {

This. Size = size;

} the & # 61692;

Clone method if the class can be cloned, the next step is the clone method: public Object clone() {

Try {

CounterSet obj = (CounterSet) super. Clone (); Obj. Packets = (int []) packets. The clone (); Obj. Size = size; Return obj.

} the catch (CloneNotSupportedException e) {

Throw new InternalError (" Unexpected CloneNotSUpportedException: "+ um participant etMessage ());

}

} the & # 61692;

Class methods: here's how to start writing class methods:

Protected final void setArray(int[] r1, int[] r2, int[] r3, int[] r4) throws IllegalArgumentException {

// // Ensure the arrays are of equal size // if (r1. Length! = r2.length || r1. Length! = r3. Length || r1. Length! = r4.length) throw new IllegalArgumentException("Arrays must be of the same size"; System. Arraycopy (r1, 0, r3, 0, r1. Length); System. Arraycopy (r2, 0, r4, 0, r1. Length); } the & # 61692; In any case, each class should define a toString method:

public String toString() { 
String retval = "CounterSet: "; 
 for (int i = 0; i < data.length(); i++)  {  
 retval += data.bytes.toString(); 
retval += data.packets.toString(); 
} 
return retval; 
 } 

The main method should be written at the bottom of the class if the main(String[]) method is already defined.