C # program coding specification

zhaozj2021-02-11  194

1. Purpose

In order to ensure that the procedures prepared by the company are in line with the same specifications, the program coding specifications established by the consistency and unity are guaranteed.

2. area

Applicable to software development work based on .NET platform.

3. Specification content

3.1. Code format

u All indentation is 4 spaces, using the default settings for VS.NET.

u Vertical to left parentheses and right brackets in the code.

IF (x == 0)

{

Response.write ("The user number must be entered!");

}

Not allowed to:

IF (x == 0) {

Response.write ("The user number must be entered!");

}

or:

IF (x == 0) {response.write ("The user number must be entered!");

u In order to prevent the source code editor from reading the code, each line code or comment must not exceed one display at 1024 * 800 display frequency.

u When a line is divided into a few lines, by placing the series operator in each row, it is not clear, it is clear that there is no line behind it.

u The statement placed on each line avoids more than one.

u User space before and after most operators, do not change the code's intent to make the code easy to read.

example:

INT j = i k;

Not writing

INT j = i k;

u Distribute large complex code sections into modules that are easily understood.

u When writing SQL statements, use all uppercase for keywords, use case-write mixing for database elements (such as tables, columns, and views).

u Place each primary SQL clause on a different line, which is easier to read and edit statements, for example: select firstname, lastname

From customer

Where stat = 'wa'

3.2. Note (Comment) Specification

Note specification includes: module (class) annotation specification, class properties, method comment specification, inter-code interpretation

3.2.1. Module (class) annotation specification

The module must be written in the following form:

///

/// Module number:

/// Effect:

/// Authors: Chinese name

/// Write the date:

///

If the module has a modification, you must add the following notes each time you modified:

///

/// log number:

/// Modify Description:

/// Author: modified by Chinese name

/// Modify Date:

///

3.2.2. Class attribute annotation specification

Attributes in the class must be written in the following format:

///

/// attribute description

///

3.2.3. Method Note Specification

Notes must be written in the following format before declaration of the class

///

/// Description: ///

///

Public Class Hello

{

Private string m_name;

PRIVATE date M_Date;

}

2. The variable corresponding to the attribute of the class, using the "m_" prefix in the attribute name

Public Class Hello

{

Private string m_name;

Public String Name

{

get

{

Return M_Name;

}

}

}

3. Documentary variables do not use prefix

Public Class Hello

{

Void Say ()

{

String syeword;

}

}

4. The parameter of the process uses "p_" as a parameter

Public Class Hello

{

Void Say (String P_Sayword)

{

}

}

Supplementary description:

Named an Exception variable in the abnormal capture process, in the case where there is no conflict, uniformly name E;

If there is a conflict, you can repeat E, such as: EE.

Try

{

// Your Code

Try

{

// Code

}

Catch (Exception EE)

{

// Your Code

}

}

Catch (Exception E)

{

// Your Code

}

Supplement: If you do not need to make any processing, you don't need to define an Exception instance.

example:

Try

{

// Your Code

}

Catch (Exception)

{

}

5. In view of the fact that most names are constructed by connecting several words, use case-write mixed formats to simplify their reading. The first letter of each word is capitalized.

6. The meaningful name is still used even for variables that may only appear in a few code lines. Use a single-letter variable name only for short cyclic indexes, such as I or J.

7. Using complementaries in the variable name, such as MIN / MAX, Begin / End, and Open / Close.

8. Do not use primary numbers or primary strings, such as FOR i = 1 to 7. But use naming constants, such as for i = 1 to num_days_in_week for maintenance and understanding.

3.3.2. Control Naming Rules

Control naming = web control abbrefix "_" variable name

Control Abbreviation Label LBL TEXTBOX TXT CHECKBOX CHK Button CMD ListBox Lst DropdownList DRP, etc.

3.4. Constant Name Specification

Constant numbers should also have some meaning, format is NOUN or Noun_Verb. The constant name is uppercase, and the word is separated by underline.

example:

Private const bool web_enablepagecache_default = true;

Private const INT Web_pagecacheexpiresinseconds_default = 3600;

Private const bool_eb_enablessl_default = false;

Note:

The variable name and constant name can contain 255 characters, but the name of more than 25 to 30 characters is relatively awkward. In addition, you should take a name that has the actual meaning, clearly express variables or constants, 25 or 30 characters should be sufficient.

3.5. Class (CLASS) naming specification

1. The name should be able to identify the characteristics of things.

2. The name is trying to use abbreviations, unless it is well known.

3. The name can be composed of two or three words, but usually should not be more than three.

4. In the name, all words are the first letter.

For example, Issuperuser, containing ID, all uppercase, such as CustomerID.

5. Name the class or noun phrase.

6. Less use of abbreviations.

7. Do not use underscore characters (_).

example:

Public Class FileStream

Public Class Button

Public Class String

3.6. Interface Naming Specification

The same is the same as the class naming specification, the only difference is that the interface plus "i" prefix before the name.

example:

Interface idbcommand;

Interface ibutton;

3.7. Method Naming Specification

The same name naming specification.

3.8. Name Space (Namespace) Named Specification

The same name naming specification.

转载请注明原文地址:https://www.9cbs.com/read-4203.html

New Post(0)