C # program coding standards [2004-08-22 09:47 AM | Author:
Admin | From:
Original]
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
