Int argumentOne,

int argumentTwo,

decimal argumentThree,

string argumentFour)

{

// Method body goes here.

}

// The calling code.

float result = DoSomethingFromManyArguments(

1,

1,

0.5m,

“Some text”);

8. Не объявляйте несколько переменных в одной строке, используйте отдельную строку для каждой переменной:

int customerID;

string customerName;

float salary;

9. Рекомендуется одинаково выравнивать связанные строки кода, особенно это касается объявлений переменных. Например:

Position _position;

string _customerName;

float _salary;

_customerName = “John Doe”;

_salary = DEFAULT_SALARY;

_salary += SALARY_BONUS;

_position = Position.Supervisor;

Используйте для выравнивания символы табуляции.

Соглашения о наименованиях

1. Не используйте венгерскую или другую префиксную нотацию за исключением случаев, оговоренных далее.

2. Имена локальных переменных и аргументов методов должны записываться в нотации «верблюд»:

string customerName;

private int DoSomething(int firstArgument, float secondArgument);

3. Имена закрытых полей класса должны следовать нотации «верблюд» с подчерком перед первым символом:

private string _customerName;

4. Имена открытых полей класса должны следовать нотации «Паскаль»:

public int CustomerID;

5. Имена свойств и методов класса должны следовать нотации «Паскаль»:

public bool ValidateAmount();

public bool FileExists

{

get;

}

6. Имена классов, структур и нумераторов должны следовать нотации «Паскаль»:

public class CustomerAccount

{

};

private enum WorkMode

{

Add,

Update;

}

7. Имена методов должны следовать шаблону «глагол» + «существительное» - например, “UpdateAccount”;

8. Используйте единственное, а не множественное число в именах перечислителей. Иными словами, “WorkMode” - это правильное имя, а “WorkModes” - нет;

9. Используйте значимые имена даже для закрытых методов, свойств, типов и т.д. Избегайте использовать короткие имена, такие как “a”, “b”, “n” за исключением общепринятых имен для переменных цикла “i” и“j”.

Общие принципы разработки

Культура кодирования

1. Дублирование кода в программе строго запрещается.

2. Не применяйте функциональную декомпозицию. Для повторного использования кода применяйте средства ООП, например, наследование;

3. Обязательна замена числовых и строковых литералов символическими константами. Исключение можно сделать для самоочевидных констант, таких как 0 и 1. Давайте символическим константам значимые имена;

4. Рекомендуется объединять связанные между собой константы целых типов в перечислители, а не целых типов – в абстрактные классы с открытыми статическими константными членами;

5. Разделяйте общеупотребительные константы, перечислители и вспомогательные классы посредством System Frameworks проектов;

6. Максимально следуйте практике ООД/ООП. Максимально используйте шаблоны проектирования, но делайте это в правильном контексте, как это описано в секции “Applicability” данного шаблона;

7. Избегайте длинных и сложных методов, разбивайте их на несколько коротких. При модификации кода максимально используйте рефакторинг;

8. Всегда обращайте внимание на предупреждения компилятора. Добивайтесь, чтобы их не было.

Соглашения о комментариях

1. Код должен легко читаться и без комментариев. Выражайте свои мысли при помощи алгоритмического языка, а не английского или украинского;

2. Текст комментария отделяйте от слэшей одним пробелом. Первая буква предложения должна быть прописной, в конце предложения должна стоять точка;

// This is a sample comment. This is yet another comment sentence.

3. Комментарии должны подчиняться общим правилам сворачивания строк.

4. Комментарии к методам, свойствам, классам, интерфейсам и другим конструкциям языка должны иметь XML-формат для возможной генерации программных документов в дальнейшем;

5. Не используйте комментарии в стиле C: /* … */

6. Комментарий не должен перефразировать то, что написано в коде. Старайтесь давать содержательные пояснения. Например, комментарий “Increment i by one” к коду “i++;” это плохая практика, а комментарий “Update the number of customer accounts processed” – хорошая.

Специфика Windows Forms

1. Следуйте Microsoft User Interface Guidelines, если к вам не предъявляют других требований.

2. Если два управляющих элемента служат одной цели (например, поле ввода для имени пользователя и метка перед ним), разрешается использовать тип элемента в окончании имени. Для предыдущего примера это могут быть имена “customerNameText” и “customerNameLabel” соответственно.

3. Старайтесь убирать всю бизнес-логику из форм и управляющих элементов. В обработчики событий элементов помещайте только вызовы методов;

4. Используйте нотацию «верблюд» для наименования экземпляров управляющих элементов на формах и пользовательских управляющих элементах, например, “optionsHeading”;

5. Используйте нотацию «Паскаль» для наименования классов форм и управляющих элементов, например, “ ProductList ”;

6. Стремитесь к повторному использованию UI и исходного кода. Делите ваш интерфейс на элементы; смело наследуйте формы и управляющие элементы.

Источник информации

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp