I feel that the code I write on a daily basis does not meet the requirements of the specification, so I specially found some relevant text on the Internet, the content is as follows:
Coding specifications that JAVA programmers must pay attention to
1. The significance of the existence of specifications The
application of coding specifications is particularly important for the software itself and software developers for the following reasons:
1. A good coding specification can reduce the number of software Maintenance costs, and almost no software is maintained by the original developers during its entire life cycle;
2. Good coding standards can improve the readability of software and allow developers to understand new 3. Good coding
standards can maximize the cooperation efficiency of team development;
4. Long-term normative coding can also allow developers to develop good coding habits and even exercise more rigorous thinking;
2. Naming Specifications
1. General concepts
1. Use complete English descriptors as much as possible
2. Use terms applicable to related fields
3. Use mixed case to make names readable
4. Use abbreviations as little as possible, but if they are used, they must be consistent with the entire project. 5.
Avoid using long names (less than 15 letters is a normal choice)
6. Avoid using similar names, or just names with different capitalization
7. Avoid using underscores (except static constants, etc.)
2. Identifiers Type description
1. Name of package (Package) The name of the
Package should use a complete English descriptor, which is composed of a lowercase word. And the prefix of the package name is always a top-level domain name,
usually com, edu, gov, mil, net, org, etc.;
such as: com.yjhmily.test
2. Naming of classes
The class name should be a noun, in mixed case, with the first letter of each word capitalized. Try to keep class names concise and descriptive.
Use complete words and avoid abbreviations (unless there is a unified abbreviation specification in the project or the abbreviation is more widely used, such as URL, HTML)
such as: FileDescription
3. The naming of the interface is
basically similar to the naming convention of the Class. On the basis of satisfying the Classd naming rules, ensure that the first letter at the beginning is "I", which
is easy to distinguish from ordinary Class. The implementation class name takes the second letter of the interface name to the end, and satisfies the naming convention of the class name; for
example: IMenuEngine
4. The naming of the enumeration (Enum) is
basically similar to the naming convention of the Class. On the basis of satisfying the Classd naming rules, ensure that the first letter at the beginning is "E", which
is easy to distinguish from ordinary Class.
Such as: EUserRole
5. The naming of the
exception ( Exception ) Exception ( Exception ) usually uses the letter e to represent the exception. For a custom exception class, the suffix must be Exception
such as: BusinessException
6. The naming of the method ( Method ) The
method name is a verb , using mixed case, the first letter of the first word is lowercase, and the first letter of subsequent words is uppercase.
The method name describes the action of the method as much as possible. Methods that return a value of type Boolean generally start with "is" or "has"
Such as: getCurrentUser() , addUser() , hasAuthority()
7. The first letter of the name of the parameter ( Param ) is
lowercase, and the first letter of the following words is uppercase. Parameter names are not allowed to begin with an underscore or dollar sign,
although this is syntactically allowed. Parameter names should be short and descriptive.
Such as: public UserContext getLoginUser(String loginName);
8. The name of the constant field ( Constants )
Static constant field ( static final ) All capital letters are used, and words are separated by underscores;
such as: public static final Long FEEDBACK;
public static Long USER_STATUS ;
3. Commenting Specifications
A good rule of thumb about comments to follow is:
ask yourself, if you have never seen this code, to understand this code effectively in a reasonable amount of time, you need some what's the message? ? ?
1. General concepts
1. Comments should increase code clarity
2. Keep comments concise
3. Write comments before or at the same time as writing code
4. Comment out why something is done, not just what
2. Comment what Part
1. Java file: The copyright information and the creation time and author of the file must be written;
2. Class: The purpose of the class, that is, the function performed by the class, as well as the time and author name of the class; edited by multiple people at one time or When modifying the same class,
the names of multiple people should appear in the author's name;
3. Interface: On the basis of satisfying the class annotation, the interface annotation should contain the purpose of setting the interface, how it should be used and how not to be used.
On the premise that the interface annotation is clear, the corresponding implementation class may not be annotated;
4. Method annotation: For the methods of setting (Set method) and obtaining (Get method) members, if the member variables have been described,
they can be omitted. Comments; common member methods are required to explain what functions are performed, what the parameters mean and what the return value is; in addition, the creation
time of the method must be clearly annotated, providing valuable clues for future maintenance and reading;
5. Internal comments of methods: control structure, code do What and why, processing order, etc., especially the complex logic processing part,
give detailed comments as much as possible;
6. Parameters: parameter meaning, and any other constraints or preconditions;
7. Attributes: Fields Description;
8. Local (intermediate) variables: no comments unless they have special meaning;
3. The comment format
follows the unified comment format specified by the project. Generally, the codetemplates.xml format file will be imported into IDE (Eclipse)
or used Eclipse defaults;
4. The code format specification
follows the unified code format stipulated by the project. Generally, the code is formatted directly using the default code format that comes with the IDE (Eclipse);
5. Other specifications
JSP file names
are described in complete English. Describe the functions accomplished by JSP, including a vivid verb as much as possible, the first letter is lowercase,
such as: viewMessage.jsp, editUser.jsp, etc.
6. Project-specific naming conventions
1. Persistence layer
1. Hibernate mapping files and entities
correspond exactly to database table names;
such as: Advertisement.hbm.xml , Advertisement.java
2. Data access DAO
DAO interface and implementation class names must fully conform to normal interface and implementation class names The data access methods in DAO
must be abstract enough to describe the basic CRUD operations on the database;
such as: ICrossAdDAO (interface), CrossAdDAO (implementation class)
3. HQL configuration files for various database operations
In principle, the number of HQL files is equal to the number of services in the Services layer of the system, and the HQL files are named after the service name; for
example: resource.hbm.xml
2. Service layer
1, service interface and implementation
service interface and implementation class must be completely It conforms to the naming rules of normal interfaces and implementation classes; the service name defined by the project is named as the main body
and ends with "Serv",
such as: IResourceServ (service interface), ResourceServ (interface implementation class)
2. The method name of the service interface method
is a verb , using mixed case, the first letter of the first word is lowercase, and the first letter of subsequent words is uppercase.
The method name describes the action of the method as much as possible.
The return type is Boolean value: start with "is" or "has" to
get some data: get+ data description noun plural + data type;
Get all data: get+All+ data description noun plural + data type;
get/query a data through XXX: get/query+ data description noun plural + data type + By+ condition;
add a certain data: save/add+ data description noun()
update A data: save/update+ data description term;
delete a data: delete/remove+ data description term;
3. Business object
business name + BO
4. Query parameter objects
All query parameter classes that inherit Abst***QuerySpec all meet the following rules:
Query+ When the data description term to be queried + Spec
is passed in as a parameter, the parameter name must be: the data description term to be queried + Spec
such as: QueryProgramSpec
3, MVC layer
1, Action control layer
Action class name: function module name + Action;
The Actoin method name describes the destination of the page migration as much as possible,
such as: LoginAction (action for login), toWelcome (action method for turning to the welcome page)
2. Resource file
system global resource file: globalMessages_+ character encoding type +
inside the .properties function module Resource files: package.properties
4, Spring configuration file
1, Action related configuration files
File directory: WebRoot/WEB-INF/spring/action/ function module name +_ApplicationContext.xml
2. Services related configuration file
directory: WebRoot/WEB-INF/spring/services/Services_ApplicationContext.xml
3. Global configuration
file directory : WebRoot/WEB-INF/spring/project name+_ApplicationContext.xml
Original link address: https://blog.csdn.net/dahe5/article/details/8615338