C # code specifications (essential tips for programmers)

1. Introduction

This article is a set of development specifications for C # programmer and C # developer.

Developing a C # program following this specification can bring the following benefits:

· Code compilation is consistent,

· Improve code readability and maintainability,

· Code sharing between programmers when a team develops a project

· Easy code review,

This is the first version. It is applicable only to general rules and cannot cover all situations.

2. file organization

2.1 C # source file

The class name or file name should be brief and should not exceed 2000LOC. Separate the code to make the structure clear. Put each class in a separate file and use the class name to name the file name (of course, the extension is. cs ). Such an agreement will make your work easier.

2.2 Directory design

Create a directory for each namespace. (Use MyProject/TestSuite/TestTier as MyProject. testSuite. testTier path, instead of using the namespace name with a dot as the path). This makes it easier to map the namespace to the directory hierarchy.

3. indent

3.1 line feed

When an expression contains more than one row, it is processed according to these general principles:

· Wrap a line after a comma.

· Line feed after the operator.

· Line feed at the top layer rather than at the lower layer.

· The line is aligned with the start position of the expression at the same layer of the previous statement.

Method call line feed example:

LongMethodCall (expr1, expr2,

Expr3, expr4, expr5 );

Arithmetic expression line feed example:

Recommended:

Var = a * B/(c-g + f) +

4 * z;

Bad format-avoid:

Var = a * B/(c-g +

F) + 4 * z;

We recommend that you use the first method, because the line is broken out of the brackets expression (the High-Level LINE folding principle ). Note that you should use a tab to the indent position, and then use a space to the line position. In our example:

> Var = a * B/(c-g + f) +

>... 4 * z;

> It indicates a tab, and. indicates a space character. (Tabs are left blank with tab indentation ). A good coding habit is to display tabs and space characters in the editor used.

3.2 Blank

There has never been a uniform standard for indentation using spaces. Some people prefer to use two spaces, some prefer to use four spaces, while others prefer to use eight spaces. Some even prefer to use more spaces. A good practice is to use tabs. Tabs have some advantages:

· Everyone can set the indentation level they like.

· It is only one character rather than 2, 4, 8, and so on, so it will reduce the input (even because of automatic indentation, sometimes you have to manually set indentation or cancel settings, and so on ).

· If you want to increase or decrease indentation, you can mark one piece and use the Tab to increase the indentation level, while Shift-Tab to reduce the indentation level. This applies to almost any text editor.

Here, we define tabs as standard indentations.

Do not indent with spaces-use tabs!

4. Notes

4.1 comments

Block annotations should be avoided. We recommend that you use the // annotation as the C # standard statement. If you want to use block annotations, you should use the following style:

/* Line 1

* Line 2

* Line 3

*/

This is because the comments block and the code block can be separated for readers. Although C-style single-line annotations are not recommended, you can still use them. Once this method is used, there should be a broken line after the comment line, because it is hard to see the code with comments in front of the same line:

/* Blah */

Block annotations are useful in rare cases. Block comments are usually used to comment out large code segments.

4.2 single line comment

You should use the // annotation style to "comment out" the Code (shortcut key, Alt + /). It can also be used for comments of code.

When a single line comment is used for code description, it must be indented to the corresponding encoding level. The commented-out code should be commented out in the first line to make it easier to see the commented-out code.

One piece of experience is that the length of comments should not exceed the length of the interpreted code, because it indicates that the code is too complex and has potential bugs.

4.3 file comment

In the. net Framework, Microsoft has introduced a file based on XML annotations. These files are the C # comments of a regular single row containing XML labels. They follow the single-line comment mode:

/// <Summary>

/// This class...

/// </Summary>

Multi-line XML annotations follow this mode:

/// <Exception cref = "BogusException">

/// This exception gets thrown as soon as

/// Bogus flag gets set.

/// </Exception>

To be recognized as an XML comment row, all rows must start with three backslashes. There are two types of labels:

· Description

· Format/reference

The first type includes labels like <summary>, <param> or <exception>. Description items of these documents describing the API elements of a program must be clearly written to facilitate other programmers. As shown in the preceding multi-line annotation example, these labels generally have names or cref attributes. The compiler checks these attributes, so they must be valid and correct. The second type uses labels such as <code>, <list> or <para> to control the layout of the remarks.

Files can be generated using the 'create' menu in the 'file' menu. Files are generated in HTML format.

5. Statement

5.1 declarations per line

We recommend that each row have only one declaration, because it can be easily annotated.

Int level; // indentation level

Int size; // size of table

When declaring a variable, do not place multiple variables or different types of variables in the same row. For example:

Int a, B; // What is? What does B stand?

The preceding example also shows the non-obvious defect of the variable name. Be clear when naming variables.

5.2 Initialization

Local variables must be initialized once declared. For example:

String name = myObject. Name;

Or

Int val = time. Hours;

Note: If you initialize a dialog, use the using statement:

Using (OpenFileDialog openFileDialog = new OpenFileDialog ()){

...

}

5.3 class and interface declaration

When writing C # classes and interfaces, follow the following formatting rules:

· Do not use spaces between the method name and the parameter list starting with parentheses.

· Start with the braces "{" sign in the next line of the statement.

· End with "}" and match with the corresponding start sign through its indentation.

For example:

Class MySample: MyClass, IMyInterface

{

Int myInt;

Public MySample (int myInt)

{

This. myInt = myInt;

}

Void Inc ()

{

++ MyInt;

}

Void EmptyMethod ()

{

}

}

For the position of a braces, see section 10.1.

6. Statements

6.1 simple statements

Each line should contain only one statement.

6.2 Return Statement

Do not use peripheral parentheses for a return statement. No:

Return (n * (n + 1)/2 );

Use: return n * (n + 1)/2;

6.3 If, if-else, if else-if else statement

If, if-else and if else-if else statements should look like this:

If (condition ){

DoSomething ();

...

}

If (condition ){

DoSomething ();

...

} Else {

DoSomethingOther ();

...

}

If (condition ){

DoSomething ();

...

} Else if (condition ){

DoSomethingOther ();

...

} Else {

DoSomethingOtherAgain ();

...

}

6.4 for/foreach statement

A for statement should be in the following format:

For (int I = 0; I <5; ++ I ){

...

}

Or place a row (consider replacing it with a while statement)

For (initialization; condition; update );

Foreach statement