Not so long ago, in comments to the topic, AlexS expressed the idea of ​​using an agreement on the design on Habré of code of examples of .Net themes written in C #.

I studied a few suggestions from these sources:
submain.com/blog/FreeCVBNETCodingGuidelinesEbookDownload.aspx
idesign.net/idesign/DesktopDefault.aspx
and compiled a draft that describes the most basic rules for writing code written in C #.

I propose:
- discuss this draft;
- make all necessary changes to it;
- approve as standard writing C # code on Habré.
Moreover, I propose creating a document that could be offered as a recommendation by habrahabr comunity for all other C # programmers.

Under the cut you will find the draft text. I invite everyone to discuss it and subject it to proper editing.

1. Requirements

1.1 Pascal casing

Names are described:
• all type definitions, including custom classes, enumerations, events, delegates, and structures;
• values ​​of transfers;
• readonly fields and constants;
• interfaces;
• methods;
• namespaces (namespace);
• properties;
• public fields;

namespace SampleNamespace
{
  enum SampleEnum
  {
    FirstValue,
    SecondValue
  }

  struct SampleStruct
  {
    public int FirstField;
    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;
• arguments of methods;
• 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 “Exception” suffix;
• interface names always begin with the prefix “I”;
• names of user attributes always end with the suffix "Attribute";
• the names of delegates for event handlers always end with the suffix EventHandler, the names of the successor classes from EventArgs always end with the suffix EventArgs.

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 ()
  {
  }
} public delegate void AnswerCreatedEventHandler (object sender, AnswerCreatedEventArgs e);
  public class AnswerCreatedEventArgs: EventArgs
  {
    public int СreatedId;
    public int ParentId;
    public string CreatorName;
  } * This source code was highlighted with Source Code Highlighter .

* This source code was highlighted with Source Code Highlighter .

1.4 Abbreviations

When using abbreviations in names, capitalization is subject to abbreviations with two characters, in other abbreviations only the first character must be reduced to upper case.

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 methods

ShowUserInfo ()

In the particular case, for methods that return a value, use the verb-object in the pair for the verb “Get”, and for the object, use the description of the returned value.

GetUserId ()

2.2 Variables, fields and properties

• When naming variables, avoid using shorthand options like I and t , use index and temp . Do not use Hungarian notation or use it only for private members. Do not shorten words, use number , not num .
• It is recommended that you specify prefixes for the names of controls that describe the type of element. For example: txtSample, lblSample, cmdSample or btnSample. The same recommendation applies to local variables of complex types: ThisIsLongTypeName tltnSample = new ThisIsLongTypeName ();
• do not use public or protected fields, use properties instead;
• use automatic properties;
• always specify the private access modifier, even if it is allowed to omit it;
• Always initialize variables, even when automatic initialization exists.

2.3 Additional recommendations

• use an empty line between logical sections in the source file, class, method;
• use an intermediate variable to pass the bool value of the result of the function to the conditional expression if ;

bool boolVariable = GetBoolValue ();
if (boolVariable)
{
} * This source code was highlighted with Source Code Highlighter .

2.4 Code Size

• 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 pass 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 prefix “m_”, the rest of the name is described using Pascal Casing.

private int m_SamplePrivateField;

Second option.
Names of private fields always begin with the prefix “m”; the rest of the name is described using Pascal Casing.

private int mSamplePrivateField;

The third option (so far the most probable for the final version)
Names of private fields 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 is included in the expression;