I. general conventions
1. Use of curly braces
-
- YesPlace the left curly braces at the end of the previous statement.
If (someexpression ){
Dosomething ();
}
-
- YesAlign the right curly braces with the beginning of the row where the left curly braces are located, unless there is only one statement in the curly braces.
If
(Someexpression ){
Dosomething ();
}
-
- YesPlace the right curly braces at the beginning of the new row.
If (someexpression ){
Dosomething ();
}
-
- ConsiderationsPut only one statementCodeBlock and left and right curly braces are written in the same line. This style is often used for Attribute access methods.
Public int
Foo {
Get {return Foo ;}
Set {Foo = value ;}
}
-
- ConsiderationsWrite All curly braces for attributes with only one access method in the same row.
Public int Foo {get {return
Foo ;}}
- YesPlace the right curly braces in a single row, unless it is followed by else, else if, or while.
If
(Someexpression ){
Do {
Dosomething ();
}
While (someothercondition );
}
-
- AvoidOmit curly braces, even ifProgramming LanguageThis is allowed.
Brackets cannot be omitted. Brackets should be used even for code blocks with only one statement. This enhances the readability and maintainability of the Code.
For
(INT I = 0; I <100; I ++) {dosomething (I );
}
Curly braces can be omitted only in rare cases. For example, it is impossible or rare to add a new statement after the original one. For example, it is meaningless to add any statement after the throw statement:
If
(Someexpression) throw new
Argumentoutofrangeexception (...);
Another exception in this article is the case statement. The case and break statements indicate the beginning and end of the code block, so these curly braces can be omitted.
2. Use of spaces
- Add a space after the left curly braces and before the right curly braces.
Public int Foo {get {return Foo ;}< BR >}
- avoid adding spaces before the left curly braces.
Best Practice: If (someexpression) {
acceptable: If
(someexpression) {
- to Add a space after a comma between the form parameters.
correct: Public void Foo (char bar, int X,
int y)
error: Public void Foo (char bar, int X, int y)
- avoid adding a space before the actual parameter.
Best Practice: Foo (mychar,)
acceptable: Foo (mychar,
0, 1)
- avoid adding spaces after the left or right parentheses.
Best Practice: Foo (mychar,)
acceptable: Foo (
mychar, 0, 1)
- do not Add a space between the member name and the left parentheses.
correct: Foo ()
error: Foo ()
- do not Add a space after the left square brackets and before the right square brackets.
correct: x = dataarray [Index];
error: x =
dataarray [Index];
- do not Add a space before the control flow statement.
correct: While (x = y)
error: While (x = y)
- avoid adding spaces before and after binary operators.
it is best to: If (x = y ){...}
acceptable: If (x =
Y ){...}
- do not Add spaces before or after the unary operator.
correct: If (! Y) {...}
error: If (! Y) {...}
3. Use of indentation
- YesIndent with four consecutive space characters.
- NoTab is used for indentation.
- YesIndent the content in the code block.
If (someexpression ){
Dosomething ();
}
- YesIndent the case code block, although no curly braces are used.
Switch (someexpression ){
Case 0:
Dosomething ();
Break;
...
}
Ii. Naming Conventions
- YesFollow the naming rules in the framework design guidelines when naming the identifiers, unless they are internal and private fields.
- YesUse the pascalcasing case-sensitive style for namespaces, types, and members, unless it is an internal field or a private field.
- YesUse the camelcasing case-sensitive style to name internal and private fields.
- YesUse the camelcasing case-sensitive style to name local variables.
- YesUses the camelcasing case-sensitive style to name the formal parameters of the method.
- NoUse the Hungarian naming method (that is, do not include the type of the variable in the variable name ).
- AvoidAdd a prefix to the local variable.
- YesUse the corresponding alias in the C # language. Do not use the type name in the. NET Framework.
For example, to use int instead of int32, use object instead of object.
3. Notes
- NoUse annotations to describe things that are obvious to anyone.
- AvoidUse the block comment syntax (/*...*/). Even if the comment has multiple lines, it is best to use the single line comment syntax (//...).
// This
Is a very long content.
// This is a very long content.
// This is a very
Long content.
Public class list <t>: ilist <t>, ilist {
...
}
- NoPlace the comment at the end of the line unless the comment is very short.
// Avoid
Public class
Arraylist {
Private int count; //-1 indicates uninitialized Array
}
Iv. Document Organization
- do not include more than one public type in a source file, unless there are nested classes, or the difference between different types is only the number of generic parameters.
multiple internal types in a file are allowed.
- to use the same name to name the source file and its public types.
for example, the string class should be in the string. CS file, and the list class should be in the list. CS file.
- Yes use the same hierarchy to organize file directories and namespaces.
for example, you should put the source file system. Collections. Generic. List in the system \ collections \ Generic Directory.
- consider grouping members based on the sequence and group given below:
1. All fields.
2. All constructors.
3. Public attributes and protected attributes.
4. method.
5. Events.
6. All explicitly implemented interface members.
7. Internal member.
8. Private member.
9. All nested types.
- place the publicly accessible members and the explicitly implemented interface members in your # region block.
# region internal
Members
...
# endregion
# region Private Members
...
# endregion
- consider organizing members in each group in alphabetical order.
- consider organizing heavy load members in a simple to complex order.
- Yes place the using Command outside the namespace declaration.
using system;
namespace
system. Collections {
...
}
