. NET encoding Specification

1. Purpose

In order to ensure that all the programs compiled by the enterprise comply with the same standards and ensure consistency and uniformity, the program coding standards are established.

2. Scope

Applicable to All enterprise software development work based on the. NET platform.

3. Standard content

3.1. Code Format

All the indentation of u is 4 spaces, and the default settings of VS. NET are used.

U vertically alignment the Left and Right brackets in the code.

If (x = 0)

{

Response. Write ("User ID is required! ");

}

The following situations are not allowed:

If (x = 0 ){

Response. Write ("User ID is required! ");

}

Or:

If (x = 0) {Response. Write ("User ID is required! ");}

U in order to avoid having to scroll the source code editor while reading the code, each line of code or comment must not exceed one display screen at a display frequency of 1024*800

When a row is divided into several rows, the concatenation operator is placed at the end of each row rather than the beginning, clearly indicating that the rows without the end are incomplete.

U to avoid more than one statement placed on each row.

U uses spaces before and after most operators. In this way, the Code intent is not changed, but the code can be easily read.

Example:

Int j = I + k;

Instead of writing

Int j = I + k;

U divides large complex code sections into small and easy-to-understand modules.

U when writing SQL statements, all keywords are capitalized, and database elements (such as tables, columns, and views) are case-insensitive.

U puts each major SQL clause on different rows, which makes it easier to read and edit statements, such as SELECT FirstName and LastName.

FROM MERs

WHERE State = 'wa'

3.2. Comment specifications

Annotation specifications include: module (class) annotation specification, class attributes, method annotation specification, and inter-code annotation

3.2.1. Module (class) annotation Specification

Module comments must be written in the following form at the beginning:

///

/// Module No.: <module No., which can be referenced in system design>

/// Function: <the description of this class can reference the description in system design>

/// Author: Chinese name of the author

/// Write date: <module creation date, format: YYYY-MM-DD>

///

If the module has been modified, the following notes must be added for each modification:

///

/// Log No.: ID, which is added once from 1>

/// Modify Description: <description of the change>

/// Author: modifier's Chinese name

/// Modification date: <module modification date, format: YYYY-MM-DD>

///

3.2.2. Class Attribute annotation Specification

Attribute comments must be written in the following format for class attributes:

///

/// Attribute description

///

3.2.3. Method annotation specifications

Annotations must be written in the following format before the class method declaration

///

/// Description: <description of this method>

///

/// <Parameter description>

///

/// <Description of the return value of the method, which must specify the meaning of the returned value>

///

3.2.4. Code comments

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, and so on ).

3.3. Variable naming rules

3.3.1. variable naming rules in the program file (*. cs)

In the program, the variable name = the prefix of the variable + the English word or word abbreviation that represents the meaning of the variable.

1. Use "m _" as the prefix for class module-level variables

Public class hello

{

Private string m_Name;

Private DateTime m_Date;

}

2. the variables corresponding to the class attributes are prefixed with "m _" before the attribute names.

Public class hello

{

Private string m_Name;

Public string Name

{

Get

{

Return m_Name;

}

}

}

3. Process-level variables do not use prefix

Public class hello

{

Void say ()

{

String SayWord;

}

}

4. The process parameter uses "p _" as the parameter

Public class hello

{

Void say (string p_SayWord)

{

}

}

Note:

Name the Exception variable in the Exception capture process. If no conflict exists, name it e;

If there is a conflict, you can repeat e, for example, ee.

Try

{

// Your code

Try

{

// Code

}

Catch (Exception ee)

{

// Your code

}

}

Catch (Exception e)

{

// Your code

}

Supplement: if you do not need to handle exceptions, you do not need to define an Exception instance.

Example:

Try

{

// Your code

}

Catch (Exception)

{

}

5. Since most names are constructed by concatenating several words, use a mix of upper and lower cases to simplify their reading. The first letter of each word is in uppercase.

6. Even for variables that may only have a short lifetime in several lines of code, they still use meaningful names. Only use single-letter variable names for short-cycle indexes, such as I or j.

7. Use complementary pairs in variable names, such as min/max, begin/end, and open/close.

8. Do not use the original numeric or string, such as For I = 1 To 7. Instead, we use a naming constant, For example, For I = 1 To NUM_DAYS_IN_WEEK, To facilitate maintenance and understanding.

3.3.2. Control naming rules

Control name = Web control abbreviation prefix + "_" + variable name