Reply to thread

Message

C# Sourcefiles
Keep your classes/files short, don't exceed 2000 LOC, divide your code up, make structures clearer. Put every class in a separate file and name the file like the class name (with .cs as extension of course). This convention makes things much easier.

Indentation
Setup visual studio to use 2 spaces as identation

Comments
Block comments:
Block comments should usually be avoided. For descriptions use of the /// comments to give C# standard descriptions is recommended. When you wish to use block comments you should use the following style :

Single line comments:
You should use the // comment style to "comment out" code (SharpDevelop has a key for it, Alt+/) . It may be used for commenting sections of code too.

Single line comments must be indented to the indent level when they are used for code documentation. Commented out code should be commented out in the first line to enhance the visibility of commented out code.

A rule of thumb says that generally, the length of a comment should not exceed the length of the code explained by too much, as this is an indication of too complicated, potentially buggy, code.

Documentation comments:
In the .net framework, Microsoft has introduced a documentation generation system based on XML comments. These comments are formally single line C# comments containing XML tags. They follow this pattern for single line comments:
[code]
/// <summary>
/// This class...
/// </summary>
[/code]
Multiline XML comments follow this pattern:
[code]
/// <exception cref=”BogusException”>
/// This exception gets thrown as soon as a
/// Bogus flag gets set.
/// </exception>
[/code]
#

All lines must be preceded by three slashes to be accepted as XML comment lines. Tags fall into two categories:
# Documentation items
# Formatting/ Referencing

The first category contains tags like <summary>, <param> or <exception>. These represent items that represent the elements of a program's API which must be documented for the program to be useful to other programmers. These tags usually have attributes such as name or cref as demonstrated in the multiline example above. These attributes are checked by the compiler, so they should be valid. The latter category governs the layout of the documentation, using tags such as <code>, <list> or <para>.
Documentation can then be generated using the 'documentation' item in the #develop 'build' menu. The documentation generated is in HTMLHelp format.
For a fuller explanation of XML comments see the Microsoft .net framework SDK documentation. For information on commenting best practice and further issues related to commenting, see the TechNote 'The fine Art of Commenting'.

Declarations
One declaration per line is recommended since it encourages commenting1. In other words,

[code]
int level; // indentation level
int size; // size of table
[/code]
Do not put more than one variable or variables of different types on the same line when declaring them. Example:

[code]
int a, b; //What is 'a'? What does 'b' stand for?
[/code]
The above example also demonstrates the drawbacks of non-obvious variable names. Be clear when naming variables.

Class and Interface Declarations
#

When coding C# classes and interfaces, the following formatting rules should be followed:
# No space between a method name and the parenthesis " (" starting its parameter list.
# The opening brace "{" appears in the next line after the declaration statement
# The closing brace "}" starts a line by itself indented to match its corresponding opening brace.

For example:

[code]
Class MySample : MyClass, IMyInterface
{
int myInt;
public MySample(int myInt)
{
this.myInt = myInt ;
}
void Inc()
{
++myInt;
}
void EmptyMethod()
{
}
}
[/code]
For a brace placement example look at section 10.1.

If, if-else, if else-if else Statements

[code]
if (condition)
{
DoSomething();
...
}
if (condition)
{
DoSomething();
...
}
else
{
DoSomethingOther();
...
}
if (condition)
{
DoSomething();
...
}
else if (condition)
{
DoSomethingOther();
...
}
else
{
DoSomethingOtherAgain();
...
}
[/code]

For / Foreach Statements
A for statement shoud have following form :

[code]
for (int i = 0; i < 5; ++i)
{
...
}
[/code]

or single lined (consider using a while statement instead) :

for (initialization; condition; update) ;
A foreach should look like :
[code]
foreach (int i in IntList)
{
 ...
}
[/code]

While/do-while Statements
A while statement should be written as follows:

[code]
while (condition)
{
...
}
[/code]

An empty while should have the following form:

[code]
while (condition) ;
[/code]
A do-while statement should have the following form:

[code]
do
{
...
} while (condition);
[/code]

Switch Statements
[code]
switch (condition)
{
case A:
...
break;
case B:
...
break;
default:
...
break;
}
[/code]

Try-catch Statements
A try-catch statement should follow this form:

[code]
try
{
...
} catch (Exception)
{
...
}
finally
{
}
[/code]

White space
#
Blank Lines

Blank lines improve readability. They set off blocks of code which are in themselves logically related. Two blank lines should always be used between:
# Logical sections of a source file
# Class and interface definitions (try one class/interface per file to prevent this case) One blank line should always be used between:
# Methods
# Properties
# Local variables in a method and its first statement
# Logical sections inside a method to improve readability Note that blank lines must be indented as they would contain a statement this makes insertion in these lines much easier.

Inter-term spacing
There should be a single space after a comma or a semicolon, for example:

[code]
TestMethod(a, b, c); don't use : TestMethod(a,b,c)
[/code]

[code]
TestMethod( a, b, c );
Single spaces surround operators (except unary operators like increment or logical not), example:
a = b; // don't use a=b;
for (int i = 0; i < 10; ++i) // don't use for (int i=0; i<10; ++i)
// or
// for(int i=0;i<10;++i)
[/code]

Table like formatting

A logical block of lines should be formatted as a table:

[code]
string name = "Mr. Ed";
int myValue = 5;
Test aTest = Test.TestYou;
[/code]
Use spaces for the table like formatting and not tabs because the table formatting may look strange in special tab intent levels.

Naming Conventions
Capitalization Styles

Pascal Casing

This convention capitalizes the first character of each word (as in TestCounter).

Camel Casing

This convention capitalizes the first character of each word except the first one. E.g. testCounter.

Upper case

Only use all upper case for identifiers if it consists of an abbreviation which is one or two characters long, identifiers of three or more characters should use Pascal Casing instead. For Example:

[code]
public class Math
{
public const PI = ...
public const E = ...
public const feigenBaumNumber = ...
}
[/code]

Naming Guidelines

Generally the use of underscore characters inside names and naming according to the guidelines for Hungarian notation are considered bad practice.

Hungarian notation is a defined set of pre and postfixes which are applied to names to reflect the type of the variable. This style of naming was widely used in early Windows programming, but now is obsolete or at least should be considered deprecated. Using Hungarian notation is not allowed if you follow this guide.

And remember: a good variable name describes the semantic not the type.

An exception to this rule is GUI code. All fields and variable names that contain GUI elements like button should be postfixed with their type name without abbreviations. For example:

[code]
System.Windows.Forms.Button cancelButton;
System.Windows.Forms.TextBox nameTextBox;
[/code]

Class Naming Guidelines
# Class names must be nouns or noun phrases.
# UsePascal Casing
# Do not use any class prefix

Interface Naming Guidelines
# Name interfaces with nouns or noun phrases or adjectives describing behavior. (Example IComponent or IEnumberable)
# Use Pascal Casing
# Use I as prefix for the name, it is followed by a capital letter (first char of the interface name)

Enum Naming Guidelines
# Use Pascal Casing for enum value names and enum type names
# Don’t prefix (or suffix) a enum type or enum values
# Use singular names for enums
# Use plural name for bit fields.

ReadOnly and Const Field Names
# Name static fields with nouns, noun phrases or abbreviations for nouns
# Use Pascal Casing

Parameter/non const field Names
# Do use descriptive names, which should be enough to determine the variable meaning and it’s type. But prefer a name that’s based on the parameter’s meaning.
# Use Camel Casing

Variable Names
# Counting variables are preferably called i, j, k, l, m, n when used in 'trivial' counting loops. (see 10.2 for an example on more intelligent naming for global counters etc.)
# Use Camel Casing

Method Names
# Name methods with verbs or verb phrases.
# Use Pascal Casing

Property Names
# Name properties using nouns or noun phrases
# Use Pascal Casing
# Consider naming a property with the same name as it’s type

Event Names
# Name event handlers with the EventHandler suffix.
# Use two parameters named sender and e
# Use Pascal Casing
# Name event argument classes with the EventArgs suffix.
# Name event names that have a concept of pre and post using the present and past tense.
# Consider naming events using a verb.

[code]
Capitalization summary
Type Case Notes
Class / Struct Pascal Casing
Interface Pascal Casing Starts with I
Enum values Pascal Casing
Enum type Pascal Casing
Events Pascal Casing
Exception class Pascal Casing End with Exception
public Fields Pascal Casing
Methods Pascal Casing
Namespace Pascal Casing
Property Pascal Casing
Protected Fields Camel Casing
private Fields Camel Casing
Parameters Camel Casing
[/code]

<blockquote data-quote="Frodo" data-source="post: 6037" data-attributes="member: 10277">C# SourcefilesKeep your classes/files short, don't exceed 2000 LOC, divide your code up, make structures clearer. Put every class in a separate file and name the file like the class name (with .cs as extension of course). This convention makes things much easier.IndentationSetup visual studio to use 2 spaces as identationCommentsBlock comments:Block comments should usually be avoided. For descriptions use of the /// comments to give C# standard descriptions is recommended. When you wish to use block comments you should use the following style :Single line comments:You should use the // comment style to &quot;comment out&quot; code (SharpDevelop has a key for it, Alt+/) . It may be used for commenting sections of code too.Single line comments must be indented to the indent level when they are used for code documentation. Commented out code should be commented out in the first line to enhance the visibility of commented out code.A rule of thumb says that generally, the length of a comment should not exceed the length of the code explained by too much, as this is an indication of too complicated, potentially buggy, code. Documentation comments:In the .net framework, Microsoft has introduced a documentation generation system based on XML comments. These comments are formally single line C# comments containing XML tags. They follow this pattern for single line comments:[code]/// &lt;summary&gt;/// This class.../// &lt;/summary&gt;[/code]Multiline XML comments follow this pattern:[code]/// &lt;exception cref=”BogusException”&gt;/// This exception gets thrown as soon as a/// Bogus flag gets set./// &lt;/exception&gt;[/code]#All lines must be preceded by three slashes to be accepted as XML comment lines. Tags fall into two categories:# Documentation items# Formatting/ ReferencingThe first category contains tags like &lt;summary&gt;, &lt;param&gt; or &lt;exception&gt;. These represent items that represent the elements of a program's API which must be documented for the program to be useful to other programmers. These tags usually have attributes such as name or cref as demonstrated in the multiline example above. These attributes are checked by the compiler, so they should be valid. The latter category governs the layout of the documentation, using tags such as &lt;code&gt;, &lt;list&gt; or &lt;para&gt;.Documentation can then be generated using the 'documentation' item in the #develop 'build' menu. The documentation generated is in HTMLHelp format.For a fuller explanation of XML comments see the Microsoft .net framework SDK documentation. For information on commenting best practice and further issues related to commenting, see the TechNote 'The fine Art of Commenting'. DeclarationsOne declaration per line is recommended since it encourages commenting1. In other words,[code]int level; // indentation levelint size; // size of table[/code]Do not put more than one variable or variables of different types on the same line when declaring them. Example:[code]int a, b; //What is 'a'? What does 'b' stand for?[/code]The above example also demonstrates the drawbacks of non-obvious variable names. Be clear when naming variables. Class and Interface Declarations#When coding C# classes and interfaces, the following formatting rules should be followed:# No space between a method name and the parenthesis &quot; (&quot; starting its parameter list.# The opening brace &quot;{&quot; appears in the next line after the declaration statement# The closing brace &quot;}&quot; starts a line by itself indented to match its corresponding opening brace.For example:[code]Class MySample : MyClass, IMyInterface{&nbsp; &nbsp; int myInt;&nbsp; &nbsp; public MySample(int myInt)&nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; this.myInt = myInt ;&nbsp; &nbsp; }&nbsp; &nbsp; void Inc()&nbsp; &nbsp; {&nbsp; &nbsp; &nbsp; ++myInt;&nbsp; &nbsp; }&nbsp; &nbsp; void EmptyMethod()&nbsp; &nbsp; {&nbsp; &nbsp; }}[/code]For a brace placement example look at section 10.1.If, if-else, if else-if else Statements[code]if (condition) {&nbsp; DoSomething();&nbsp; ...}if (condition) {&nbsp; DoSomething();&nbsp; ...} else {&nbsp; DoSomethingOther();&nbsp; ...}if (condition) {&nbsp; DoSomething();&nbsp; ...} else if (condition) {&nbsp; DoSomethingOther();&nbsp; ...} else {&nbsp; DoSomethingOtherAgain();&nbsp; ...}[/code]For / Foreach StatementsA for statement shoud have following form :[code]for (int i = 0; i &lt; 5; ++i) {&nbsp; ...}[/code]or single lined (consider using a while statement instead) :for (initialization; condition; update) ;A foreach should look like :[code]&nbsp; foreach (int i in IntList) &nbsp; {&nbsp; &nbsp;&nbsp; ...&nbsp; }[/code]While/do-while StatementsA while statement should be written as follows:[code]while (condition) {&nbsp; ...}[/code]An empty while should have the following form:[code]while (condition) ;[/code]A do-while statement should have the following form:[code]do {&nbsp; ...} while (condition);[/code]Switch Statements[code]switch (condition) {&nbsp; case A:&nbsp; ...&nbsp; break;&nbsp; case B:&nbsp; ...&nbsp; break;&nbsp; default:&nbsp; ...&nbsp; break;}[/code]Try-catch StatementsA try-catch statement should follow this form:[code]try {&nbsp; ...} catch (Exception) {&nbsp; ...}finally{}[/code]White space#Blank LinesBlank lines improve readability. They set off blocks of code which are in themselves logically related. Two blank lines should always be used between:# Logical sections of a source file# Class and interface definitions (try one class/interface per file to prevent this case) One blank line should always be used between:# Methods# Properties# Local variables in a method and its first statement# Logical sections inside a method to improve readability Note that blank lines must be indented as they would contain a statement this makes insertion in these lines much easier.Inter-term spacingThere should be a single space after a comma or a semicolon, for example:[code]TestMethod(a, b, c); don't use : TestMethod(a,b,c)[/code][code]TestMethod( a, b, c );Single spaces surround operators (except unary operators like increment or logical not), example:a = b; // don't use a=b;for (int i = 0; i &lt; 10; ++i) // don't use for (int i=0; i&lt;10; ++i)// or// for(int i=0;i&lt;10;++i)[/code]Table like formattingA logical block of lines should be formatted as a table:[code]string name&nbsp; &nbsp;&nbsp; = &quot;Mr. Ed&quot;;int&nbsp; &nbsp;&nbsp; myValue = 5;Test&nbsp;&nbsp; aTest&nbsp; &nbsp;&nbsp; = Test.TestYou;[/code]Use spaces for the table like formatting and not tabs because the table formatting may look strange in special tab intent levels. Naming ConventionsCapitalization StylesPascal CasingThis convention capitalizes the first character of each word (as in TestCounter).Camel CasingThis convention capitalizes the first character of each word except the first one. E.g. testCounter.Upper caseOnly use all upper case for identifiers if it consists of an abbreviation which is one or two characters long, identifiers of three or more characters should use Pascal Casing instead. For Example:[code]public class Math{&nbsp; public const PI = ...&nbsp; public const E = ...&nbsp; public const feigenBaumNumber = ...}[/code]Naming GuidelinesGenerally the use of underscore characters inside names and naming according to the guidelines for Hungarian notation are considered bad practice.Hungarian notation is a defined set of pre and postfixes which are applied to names to reflect the type of the variable. This style of naming was widely used in early Windows programming, but now is obsolete or at least should be considered deprecated. Using Hungarian notation is not allowed if you follow this guide.And remember: a good variable name describes the semantic not the type.An exception to this rule is GUI code. All fields and variable names that contain GUI elements like button should be postfixed with their type name without abbreviations. For example:[code]System.Windows.Forms.Button cancelButton;System.Windows.Forms.TextBox nameTextBox;[/code]Class Naming Guidelines# Class names must be nouns or noun phrases.# UsePascal Casing # Do not use any class prefixInterface Naming Guidelines# Name interfaces with nouns or noun phrases or adjectives describing behavior. (Example IComponent or IEnumberable)# Use Pascal Casing # Use I as prefix for the name, it is followed by a capital letter (first char of the interface name)Enum Naming Guidelines# Use Pascal Casing for enum value names and enum type names# Don’t prefix (or suffix) a enum type or enum values# Use singular names for enums# Use plural name for bit fields.ReadOnly and Const Field Names# Name static fields with nouns, noun phrases or abbreviations for nouns# Use Pascal Casing Parameter/non const field Names# Do use descriptive names, which should be enough to determine the variable meaning and it’s type. But prefer a name that’s based on the parameter’s meaning.# Use Camel Casing Variable Names# Counting variables are preferably called i, j, k, l, m, n when used in 'trivial' counting loops. (see 10.2 for an example on more intelligent naming for global counters etc.)# Use Camel Casing Method Names# Name methods with verbs or verb phrases.# Use Pascal Casing Property Names# Name properties using nouns or noun phrases# Use Pascal Casing # Consider naming a property with the same name as it’s typeEvent Names# Name event handlers with the EventHandler suffix.# Use two parameters named sender and e# Use Pascal Casing # Name event argument classes with the EventArgs suffix.# Name event names that have a concept of pre and post using the present and past tense.# Consider naming events using a verb.[code]Capitalization summaryType&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Case&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Notes&nbsp; &nbsp; Class / Struct&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pascal Casing&nbsp; &nbsp;&nbsp; Interface&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pascal Casing&nbsp; &nbsp; &nbsp; &nbsp; Starts with IEnum values&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pascal Casing&nbsp; &nbsp;&nbsp; Enum type&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pascal Casing&nbsp; &nbsp;&nbsp; Events&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pascal Casing&nbsp; &nbsp;&nbsp; Exception class&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pascal Casing&nbsp; &nbsp; &nbsp; &nbsp; End with Exceptionpublic Fields&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pascal Casing&nbsp; &nbsp;&nbsp; Methods&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pascal Casing&nbsp; &nbsp;&nbsp; Namespace&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pascal Casing&nbsp; &nbsp;&nbsp; Property&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pascal Casing&nbsp; &nbsp;&nbsp; Protected Fields&nbsp; &nbsp; &nbsp; &nbsp; Camel Casing&nbsp; &nbsp;&nbsp; private Fields&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Camel Casing&nbsp; &nbsp;&nbsp; Parameters&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Camel Casing&nbsp; &nbsp;&nbsp; [/code]</blockquote>

[QUOTE="Frodo, post: 6037, member: 10277"] [b]C# Sourcefiles[/b] Keep your classes/files short, don't exceed 2000 LOC, divide your code up, make structures clearer. Put every class in a separate file and name the file like the class name (with .cs as extension of course). This convention makes things much easier. [b]Indentation[/b] Setup visual studio to use 2 spaces as identation [b]Comments[/b] Block comments: Block comments should usually be avoided. For descriptions use of the /// comments to give C# standard descriptions is recommended. When you wish to use block comments you should use the following style : Single line comments: You should use the // comment style to "comment out" code (SharpDevelop has a key for it, Alt+/) . It may be used for commenting sections of code too. Single line comments must be indented to the indent level when they are used for code documentation. Commented out code should be commented out in the first line to enhance the visibility of commented out code. A rule of thumb says that generally, the length of a comment should not exceed the length of the code explained by too much, as this is an indication of too complicated, potentially buggy, code. Documentation comments: In the .net framework, Microsoft has introduced a documentation generation system based on XML comments. These comments are formally single line C# comments containing XML tags. They follow this pattern for single line comments: [code] /// <summary> /// This class... /// </summary> [/code] Multiline XML comments follow this pattern: [code] /// <exception cref=”BogusException”> /// This exception gets thrown as soon as a /// Bogus flag gets set. /// </exception> [/code] # All lines must be preceded by three slashes to be accepted as XML comment lines. Tags fall into two categories: # Documentation items # Formatting/ Referencing The first category contains tags like <summary>, <param> or <exception>. These represent items that represent the elements of a program's API which must be documented for the program to be useful to other programmers. These tags usually have attributes such as name or cref as demonstrated in the multiline example above. These attributes are checked by the compiler, so they should be valid. The latter category governs the layout of the documentation, using tags such as <code>, <list> or <para>. Documentation can then be generated using the 'documentation' item in the #develop 'build' menu. The documentation generated is in HTMLHelp format. For a fuller explanation of XML comments see the Microsoft .net framework SDK documentation. For information on commenting best practice and further issues related to commenting, see the TechNote 'The fine Art of Commenting'. [b]Declarations[/b] One declaration per line is recommended since it encourages commenting1. In other words, [code] int level; // indentation level int size; // size of table [/code] Do not put more than one variable or variables of different types on the same line when declaring them. Example: [code] int a, b; //What is 'a'? What does 'b' stand for? [/code] The above example also demonstrates the drawbacks of non-obvious variable names. Be clear when naming variables. [b]Class and Interface Declarations[/b] # When coding C# classes and interfaces, the following formatting rules should be followed: # No space between a method name and the parenthesis " (" starting its parameter list. # The opening brace "{" appears in the next line after the declaration statement # The closing brace "}" starts a line by itself indented to match its corresponding opening brace. For example: [code] Class MySample : MyClass, IMyInterface { int myInt; public MySample(int myInt) { this.myInt = myInt ; } void Inc() { ++myInt; } void EmptyMethod() { } } [/code] For a brace placement example look at section 10.1. [b]If, if-else, if else-if else Statements[/b] [code] if (condition) { DoSomething(); ... } if (condition) { DoSomething(); ... } else { DoSomethingOther(); ... } if (condition) { DoSomething(); ... } else if (condition) { DoSomethingOther(); ... } else { DoSomethingOtherAgain(); ... } [/code] [b]For / Foreach Statements[/b] A for statement shoud have following form : [code] for (int i = 0; i < 5; ++i) { ... } [/code] or single lined (consider using a while statement instead) : for (initialization; condition; update) ; A foreach should look like : [code] foreach (int i in IntList) { ... } [/code] [b]While/do-while Statements[/b] A while statement should be written as follows: [code] while (condition) { ... } [/code] An empty while should have the following form: [code] while (condition) ; [/code] A do-while statement should have the following form: [code] do { ... } while (condition); [/code] [b]Switch Statements[/b] [code] switch (condition) { case A: ... break; case B: ... break; default: ... break; } [/code] [b]Try-catch Statements[/b] A try-catch statement should follow this form: [code] try { ... } catch (Exception) { ... } finally { } [/code] [b]White space[/b] # Blank Lines Blank lines improve readability. They set off blocks of code which are in themselves logically related. Two blank lines should always be used between: # Logical sections of a source file # Class and interface definitions (try one class/interface per file to prevent this case) One blank line should always be used between: # Methods # Properties # Local variables in a method and its first statement # Logical sections inside a method to improve readability Note that blank lines must be indented as they would contain a statement this makes insertion in these lines much easier. Inter-term spacing There should be a single space after a comma or a semicolon, for example: [code] TestMethod(a, b, c); don't use : TestMethod(a,b,c) [/code] [code] TestMethod( a, b, c ); Single spaces surround operators (except unary operators like increment or logical not), example: a = b; // don't use a=b; for (int i = 0; i < 10; ++i) // don't use for (int i=0; i<10; ++i) // or // for(int i=0;i<10;++i) [/code] Table like formatting A logical block of lines should be formatted as a table: [code] string name = "Mr. Ed"; int myValue = 5; Test aTest = Test.TestYou; [/code] Use spaces for the table like formatting and not tabs because the table formatting may look strange in special tab intent levels. [b]Naming Conventions[/b] Capitalization Styles Pascal Casing This convention capitalizes the first character of each word (as in TestCounter). Camel Casing This convention capitalizes the first character of each word except the first one. E.g. testCounter. Upper case Only use all upper case for identifiers if it consists of an abbreviation which is one or two characters long, identifiers of three or more characters should use Pascal Casing instead. For Example: [code] public class Math { public const PI = ... public const E = ... public const feigenBaumNumber = ... } [/code] [b]Naming Guidelines[/b] Generally the use of underscore characters inside names and naming according to the guidelines for Hungarian notation are considered bad practice. Hungarian notation is a defined set of pre and postfixes which are applied to names to reflect the type of the variable. This style of naming was widely used in early Windows programming, but now is obsolete or at least should be considered deprecated. Using Hungarian notation is not allowed if you follow this guide. And remember: a good variable name describes the semantic not the type. An exception to this rule is GUI code. All fields and variable names that contain GUI elements like button should be postfixed with their type name without abbreviations. For example: [code] System.Windows.Forms.Button cancelButton; System.Windows.Forms.TextBox nameTextBox; [/code] [b]Class Naming Guidelines[/b] # Class names must be nouns or noun phrases. # UsePascal Casing # Do not use any class prefix [b]Interface Naming Guidelines[/b] # Name interfaces with nouns or noun phrases or adjectives describing behavior. (Example IComponent or IEnumberable) # Use Pascal Casing # Use I as prefix for the name, it is followed by a capital letter (first char of the interface name) [b]Enum Naming Guidelines[/b] # Use Pascal Casing for enum value names and enum type names # Don’t prefix (or suffix) a enum type or enum values # Use singular names for enums # Use plural name for bit fields. [b]ReadOnly and Const Field Names[/b] # Name static fields with nouns, noun phrases or abbreviations for nouns # Use Pascal Casing [b]Parameter/non const field Names[/b] # Do use descriptive names, which should be enough to determine the variable meaning and it’s type. But prefer a name that’s based on the parameter’s meaning. # Use Camel Casing [b]Variable Names[/b] # Counting variables are preferably called i, j, k, l, m, n when used in 'trivial' counting loops. (see 10.2 for an example on more intelligent naming for global counters etc.) # Use Camel Casing [b]Method Names[/b] # Name methods with verbs or verb phrases. # Use Pascal Casing [b]Property Names[/b] # Name properties using nouns or noun phrases # Use Pascal Casing # Consider naming a property with the same name as it’s type [b]Event Names[/b] # Name event handlers with the EventHandler suffix. # Use two parameters named sender and e # Use Pascal Casing # Name event argument classes with the EventArgs suffix. # Name event names that have a concept of pre and post using the present and past tense. # Consider naming events using a verb. [code] Capitalization summary Type Case Notes Class / Struct Pascal Casing Interface Pascal Casing Starts with I Enum values Pascal Casing Enum type Pascal Casing Events Pascal Casing Exception class Pascal Casing End with Exception public Fields Pascal Casing Methods Pascal Casing Namespace Pascal Casing Property Pascal Casing Protected Fields Camel Casing private Fields Camel Casing Parameters Camel Casing [/code] [/QUOTE]