Code design specifications and java code design specifications
Code Generation design specifications
I. annotation specifications
1. user-created code file comments
For self-created code files (such as functions and scripts), write the following comments at the beginning of the file:
/*************************************** **********
Author:
Note:
Creation date:
Version:
**************************************** ******/
2. Standard comments
Add comments to the first line of the module, class, attribute, and method to prompt the user when calling the method. The following uses the method declaration as an example:
/// <Summary>
/// <Description of this method>
/// </Summary>
/// <Paramname = "<Parameter Name>"> <parameter description> </param>
/// <Returns>
/// <Description of the return value of the method, which must specify the meaning of the returned value>
/// </Returns>
3. Comments in the code
Comments between codes can be divided into single-line comments and multi-line comments:
Single line comment:
// <Single line comment>
Multi-line comment:
/* Multi-line comment 1
Multi-line comment 2
Multi-line comment 3 */
You must add comments (if, for, foreach,…) when encountering statement blocks in the code ,......), The added comments must be able to describe the functions and implementation methods of this statement block (the algorithms used, the cyclic conditions, the meaning of different branches, and so on ).
Ii. Exception Handling
1,Data LayerAndService LayerExceptions must be recorded in service logs
Try
{}
Catch (DbEntityValidationException ex)
{ThrownewSerivceException ("");}
Catch (SerivceException ex)
{Throw ex ;}
Catch (Exception ex)
{ThrownewSerivceException ("");}
2,Business LayerAndClientExceptions must be recorded in files
Principle exception msg clearly describes the cause and key parameters of the error, so that the client users, testers, and related R & D personnel can understand the cause of the error.
3. Web pages
1. When an html tag with a half screen exceeded is displayed, add the following example: <! -- BEGIN description --> <body> </body> <! -- End description -->
2. Js naming rules
Function: fn example: fnMethod
Event: on example: eventBeforeSave
3. IF-ELSE, WHILE, or FOR statements of a single row must also be enclosed in parentheses, but they can be written as follows:
If (condition) {statement ;}
While (condition) {statement ;}
For (intialization; condition; update) {statement ;}
4,
Foreach (var item in list ){
Foreach (var item1 in list ){
Foreach (var item2 in list ){
}
}
}
Iii. Naming rules
1. Assembly naming, namespace, and class (all Chinese names)
1) Assembly: project domain name + project name + Module name example: Version June. Vendor-Business Layer
2) namespace: September June. Vendor. Business Layer. Document Management (business logic suffix 'manager ')
3) Class Name: Order
2. Method naming
1) service layer and service method naming
Mainly based on the mixed naming method, common verb words + Chinese Word descriptions + '_' + precise descriptions
Get ***// 'Get ***'
Create ***// 'Create ***'
Update ***// 'Update ***'
Del ***// 'Delete ***'
Save ***// 'Create or modify ***'
Fill ***// 'Fill *** 'is mostly used for business logic processing
Add ***// 'Add *** 'is mostly used for business logic processing
Remove ***// 'Remove *** 'is mostly used for business logic processing.
Example: public VM. Order Get order information (string order number)
Publicvoid Update order status _ warehouse picking (string order number, string operator)
The method names for obtaining multiple records must end with 'set '.
Example: publicList <VM. Order> Get order informationSet(String keyword)
3) The method parameters are all Chinese names, and the Mvc Controllers method parameters (all English) // start with lowercase letters
4) MVC distributed VIEW _ starts with an uppercase word
3. variable naming
Abbreviation of namespace reference
Business Layer: for example, using BS supplier = version June. Supplier. business layer;
Data Layer: for example, using DAO vendor = version June. Vendor. data layer;
Service layer: for example, using Server supplier = version June. Supplier. Service;
View model: for example, using VM vendor = version June. Vendor. View Model
Public Class Library: for example, using Comm = DotNet. Common;
Variable names are dominated by mixed naming
Sbyte: sbte |
Char: chr |
Short: sht |
Object: obj |
Int: int |
String: str |
Long: lng |
DateTime: dte |
Byte: bte |
IntPtr: intptr |
Ushot: usht |
Temporary Variable: tmp |
Uint: uint |
Guid: g |
Ulong: ulng |
(S, dao) entity model: model |
Float: flt |
Class private variable: m |
Double: dbl |
Static variable: st |
Decimal: dcl |
Constant: const |
Bool: is |
Global: p |
StringBulider: sb |
List: lst |
Array: arr |
Enumeration: e |
Array: |
Object from view: vm |
The general principle is to express the content in Chinese and use the variable type as the prefix. Variable types are prefixed for the convenience of indexing, and Chinese names are used for easy meaning.
Note: The above rules are not used for parameter variable naming of methods, and the above rules are used for return value variables.
Html naming rules
Name |
Description |
Standard naming example |
Doc |
Document |
|
Wnd |
Window |
|
Frm |
Form |
|
Btn |
Input type = button |
|
Ckb |
Input type = checkbox |
|
File |
Input type = file |
|
Hid |
Input type = hidden |
|
Img |
Input type = image | img |
|
Pwd |
Input type = password |
|
Rdb |
Input type = radio |
|
Rst |
Input type = rest |
|
Smt |
Input type = submit |
|
Txt |
Input type = text |
|
Sel |
Select |
|
Tar |
Textarea |
|
Table |
Tbl |
Common naming rules
Logon entry: loginBar |
Join: joinus |
Main navigation: mainNav |
Logo: logo |
Guide: guild |
Top navigation: topnav |
Sidebar: sidebar |
Service: service |
Side navigation: sidebar |
Advertisement: banner |
Hotspot: hot |
Left Navigation: leftsideBar |
Navigation: nav |
News: news |
Right navigation: rightsideBar |
Subnavigation: subNav |
Download: download |
Banner |
Menu: menu |
Registration: register |
Menu content 1: menu1Content |
Sub menu: subMenu |
Status: status |
Menu capacity: menuContainer |
Search: search |
Button: btn |
Sub menu: submenu |
Scroll: scroll |
Vote: vote |
Navigation icon: sidebarIcon |
Page subject: main |
Partner: partner |
Note: note |
Content: content |
Copyright: copyright |
Container: container |
Tab: tab |
Coat: wrap |
Login: login |
Article list: list |
Main navigation: mainNav |
Shopping Cart: shop |
Message: msg |
Subnavigation: subnav |
Current curren |
Tips: tips |
Trademark: label |
|
Footer: footer |
Entire page: content |
|
Link: friendLink |
Header: header |
|
Title: title |
||
1. Improve coding quality, code readability, and maintainability.
2 code writing specifications
2.1 Delete all useless code
2.2 you must add comments to the code. The number of comments in a class cannot be less than 20% of the Code.
2.3 we recommend that you follow the 30-second principle. If another programmer cannot know what your function is doing, how it is done, and why it is necessary within 30 seconds, it means that your code is difficult to maintain and needs to be improved.
2.4 The code length of a function cannot exceed 100 rows. A function with more than one hundred rows is recommended to be split without interrupting atomicity.
2.5 variables should be defined in the method or Class header.
2.6 ensure that only one line of code is done
2.7 use parentheses to control the operation sequence of operators, so as not to use the java default operator priority sequence.
2.8 code formatting: format the code and then submit it.
2.9 The interface does not allow declarations without methods or variables
3. Naming rules
3.1 The names of various identifiers should use meaningful English words or abbreviations. Acronyms and English words should be included in the project's abbreviated vocabulary. Do not use Arabic numerals or pinyin for naming.
3.2 Class Name: the first letter is capitalized, and the first letter of each word must be capitalized.
3.3 method name: the first letter is lowercase, and the first letter of other words must be uppercase.
3.4 global variables and constant names must be uppercase letters.
3.5 The parameter name is basically the same as that of a local variable. The difference is that the parameter name must be prefixed with a, an, or end with s at the end of the word.
4. annotation specifications
4.1 notes:
★Annotations should be clearly expressed in Chinese, and the program should look clearer and easier to understand.
★Annotations should be as concise as possible to avoid decorative comments.
★Note not only describes what to do, but also explains why to do so. It is best to write a comment to indicate what to do before encoding.
Comments of the 4.2 class
★The purpose of the class. Including introductions that are of interest to others.
★Known bugs, of course, it is best to modify all the errors, but sometimes there may be no way to modify them, or there is no time to modify them.
★Develop and maintain the Historical List of this class, and record the author, date, and content of each change.
★Lists the various stable states of a class, which indicate the changes in the class state by calling the member function (optional ).
★Synchronization problem (optional)
★The main algorithms must be described, and the main process must be guided.
Standard Format:
If you modify a version of the class, you need to add the modification history for each modification in the following format:
// Modifier + modification date
// Example of modification description:
// Li Si 2010/07/02
// Add the processing function saveBatch (
@ Bind (key = "itemParams", defaultValue = "") String itemParams,
@ Bind (key = "pid", defaultValue = "") String pid ).
// Wang xiao'er 2010/07/02
4.3 interface notes:
★The annotation style of the interface is basically the same as that of the class;
★Before using interfaces, you must understand the concepts contained in interfaces. A simple method to check whether an interface should be defined is: can you?★It is easy to describe the purpose of the interface;
★How interfaces should and should not be used. Developers need to know how the interface is used and how it cannot be used.
4.4 function comments
★The annotation of the function header must include: What functions are executed by the function, why? And what attributes of the object during function processing.
★Possible changes; function execution... remaining full text>
What is the code for designing common concrete?
The new version is 2010, and 50010 is a serial number, which refers to the "Concrete Structure Design Specifications" standard. Each standard has a serial number. 2010 indicates the standard release year. Standard No.: GB
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
