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

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

string customerName;

 

private int DoSomething(int firstArgument, float secondArgument);

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

private string _customerName;

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

public int CustomerID;

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

public bool ValidateAmount ();

public bool FileExists

{

get;

}

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

public class CustomerAccount

{

};

 

private enum WorkMode

{

Add,

Update;

}

1. Имена методов должны следовать шаблону «глагол» + «существительное» - например, “UpdateAccount”;
2. Используйте единственное, а не множественное число в именах перечислителей. Иными словами, “WorkMode” - это правильное имя, а “WorkModes” - нет;
3. Используйте значимые имена даже для закрытых методов, свойств, типов и т.д. Избегайте использовать короткие имена, такие как “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.

1. Комментарии должны подчиняться общим правилам сворачивания строк.
2. Комментарии к методам, свойствам, классам, интерфейсам и другим конструкциям языка должны иметь XML-формат для возможной генерации программных документов в дальнейшем;
3. Не используйте комментарии в стиле C: /* … */
4. Комментарий не должен перефразировать то, что написано в коде. Старайтесь давать содержательные пояснения. Например, комментарий “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