I always thought that I was still talking about programming skills. Yesterday, a teacher saw what I wrote before. Code I still need to strengthen my skills (I was very depressed at the time, but I actually know more than him ). In many cases, we pay too much attention to high-level and cutting-edge technologies. In fact, many companies ask you to write a simple Program , You may decide whether you want. They see your experience and your level from the code. These levels do not reflect your cutting-edge technologies (and many new technologies can be learned), but your style or habits, which have been accumulated through a long experience.
The following is a reference to the C # programming style collected from the Internet, hoping to be useful to readers.
[Reference] by Krzysztof cwalina and Brad Abrams in. Net Design Specifications
C # There are many different programming style conventions in the programming world, each of which has its own history and philosophy. The conventions described in this article focus on the following goals:
1. It must be used by actual developers. To achieve this, we reviewed the code written by. NET Framework developers. Some conventions are not widely used in the framework and we will not accept them.
2. The conventions should be as reasonable and concise as possible. We think it is helpful to write more code within a few lines without sacrificing the readability of the Code, because we can minimize the split screen and split lines of the Code, increase the code density (no blank lines) as much as possible ).
3. The conventions should be simple. We believe that programming conventions do not need to be detailed for every detail of each format. Too complex conventions are difficult to follow, and they do not add much value to a group of core conventions.
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 ();
}
-
- ConsiderationsWrite the code block with only one statement and the Left and Right curly braces 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
-
- YesAdd a space after the left curly braces and before the right curly braces.
Public int Foo {get {return Foo ;}}
-
- AvoidAdd a space before the left curly braces.
Best Practice: If (someexpression ){
Acceptable: If (someexpression ){
-
- YesAdd a space after a comma between formal parameters.
Correct: Public void Foo (char bar, int X, int y)
Error: Public void Foo (char bar, int X, int y)
-
- AvoidAdd a space before the actual parameter.
Best Practice: Foo (mychar, 0, 1)
Acceptable: Foo (mychar, 0, 1)
- AvoidAdd a space after the left or right parentheses.
Best Practice: Foo (mychar, 0, 1)
Acceptable: Foo (mychar, 0, 1)
-
- NoAdd a space between the member name and the left parentheses.
Correct: Foo ()
Error: Foo ()
-
- NoAdd a space after the left square brackets and before the right square brackets.
Correct: x = dataarray [Index];
Error: x = dataarray [Index];
-
- NoAdd a space before the control flow statement.
Correct: While (x = y)
Error: While (x = y)
-
- AvoidAdd spaces before and after binary operators.
Best Practice: If (x = y ){...}
Acceptable: If (x = y ){...}
-
- NoAdd 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 {
...
}
