Not so long ago, in the comments to the
topic, AlexS expressed the idea of using the agreement on the design in Habré of code examples of the .Net theme written in C #. I studied a little the available offers from these sources:
submain.com/blog/FreeCVBNETCodingGuidelinesEbookDownload.aspxidesign.net/idesign/DesktopDefault.aspxand compiled a draft that describes the most basic rules for the design of code written in C #.
I suggest:
- discuss this draft;
- make all the necessary changes to it;
- approve as a standard for writing C # code on Habré.
Moreover, I propose to create a document that could be proposed as recommendations of habrahabr comunity for all other C # programmers.
Under the cut you will find the text of the draft. I suggest everyone to discuss it and subject to a proper revision.
')
1. Requirements
1.1 Pascal casing
Names are described:
• all type definitions, including custom classes, enums, events, delegates, and structures;
• enum values;
• readonly fields and constants;
• interfaces;
• methods;
• namespaces;
• properties;
• public fields;
namespace SampleNamespace
{
enum SampleEnum
{
FirstValue,
Secondvalue
}
struct SampleStruct
{
public int FisrtField;
public int SecondField;
}
interface ISampleInterface
{
void SampleMethod ();
}
public class SampleClass: SampleInterface
{
const int SampleConstValue = 0xffffff;
readonly int SampleReadonlyField;
public int SampleProperty
{
get ;
set ;
}
public int SamplePublicField;
SampleClass ()
{
SampleReadonlyField = 1;
}
delegate void SampleDelegate ();
event SampleDelegate SampleEvent;
public void SampleMethod ()
{
}
}
} * This source code was highlighted with Source Code Highlighter .
1.2 Camel casing
Names are described:
• local variables;
• method arguments;
• protected fields.
protected int sampleProtectedField;
int SampleMethod ( int sampleArgument)
{
int sampleLocalVariable;
} * This source code was highlighted with Source Code Highlighter .
1.3 Suffixes and Prefixes
The following suffixes and prefixes are used:
• the names of custom exception classes always end with the suffix “Exception”;
• interface names always begin with the prefix “I”;
• user attribute names always end with the “Attribute” suffix;
public class SampleException: System. Exception
{
public SampleException ()
{
}
}
interface ISample
{
void SampleMethod ();
}
[System. AttributeUsage (System. AttributeTargets .All, Inherited = false , AllowMultiple = true )]
sealed class SampleAttribute: System. Attribute
{
public SampleAttribute ()
{
}
} * This source code was highlighted with Source Code Highlighter .
1.4 Abbreviations
When using abbreviations in names, two-character abbreviations are subject to capitalization, in other abbreviations only the first character should be reduced to uppercase.
namespace Sample.IO
{
}
class HttpUtil
{
} * This source code was highlighted with Source Code Highlighter .
2. Recommendations
2.1 Naming methods
Use the verb-object construct to name the methods.
ShowUserInfo ()
In the particular case, for methods that return a value, use the verb-object for the verb “Get” in a pair, and for an object, use the description of the return value.
GetUserId ()
2.2 Variables, fields and properties
• When naming variables, avoid using abbreviated variants like
I and
t , use
index and
temp . Do not use the Hungarian notation or use it only for closed members. Do not abbreviate words, use
number , not
num .
• do not use public or protected fields, use properties instead;
• use automatic properties
2.3 Additional recommendations
• use an intermediate variable to transfer the bool value of the function result to the
if conditional expression;
bool boolVariable = GetBoolValue ();
if (boolVariable)
{
} * This source code was highlighted with Source Code Highlighter .
2.4 The amount of code
• Avoid files with more than 500 lines of code;
• Avoid methods with more than 200 lines of code;
• avoid methods with more than 5 arguments, use structures to transfer a large number of parameters;
• one line of code should not be longer than 120 characters.
3. Controversial points for discussion
3.1 Closed Fields
First option
Private field names always begin with the “m_” prefix; the rest of the name is described using Pascal Casing.
private int m_SamplePrivateField;
Second option
Private field names always begin with the “m” prefix. The rest of the name is described using Pascal Casing.
private int mSamplePrivateField;
Third option
Private field names always begin with the “_” prefix. The rest of the name is described using Camel Casing.
private int _samplePrivateField;
3.2 Additional Requirements
• always place opening and closing curly braces on a new line;
• always use curly braces for the if expression, even when only one line of code enters the expression;