Длинный список параметров метода также должен быть свернут, равно как и список аргументов в инструкции вызова метода:
// The method declaration.
public float DoSomethingFromManyArguments( decimal argumentThree, string argumentFour) // The calling code.
float result = DoSomethingFromManyArguments( Не объявляйте несколько переменных в одной строке, используйте отдельную строку для каждой переменной:
string customerName;
Рекомендуется одинаково выравнивать связанные строки кода, особенно это касается объявлений переменных. Например:
Position _position;
string _customerName;
_customerName = “John Doe”;
_salary += SALARY_BONUS;
_position = Position.Supervisor;
Используйте для выравнивания символы табуляции.
Соглашения о наименованиях Не используйте венгерскую или другую префиксную нотацию за исключением случаев, оговоренных далее.
Имена локальных переменных и аргументов методов должны записываться в нотации «верблюд»:
string customerName;
private int DoSomething(int firstArgument, float secondArgument);
Имена закрытых полей класса должны следовать нотации «верблюд» с подчерком перед первым символом:
private string _customerName;
Имена открытых полей класса должны следовать нотации «Паскаль»:
public int CustomerID;
Имена свойств и методов класса должны следовать нотации «Паскаль»:
public bool ValidateAmount();
public bool FileExists Имена классов, структур и нумераторов должны следовать нотации «Паскаль»:
public class CustomerAccount private enum WorkMode Имена методов должны следовать шаблону «глагол» + «существительное» - например, “UpdateAccount”;
Используйте единственное, а не множественное число в именах перечислителей. Иными словами, “WorkMode” - это правильное имя, а “WorkModes” - нет;
Используйте значимые имена даже для закрытых методов, свойств, типов и т.д. Избегайте использовать короткие имена, такие как “a”, “b”, “n” за исключением общепринятых имен для переменных цикла “i” и“j”.
Общие принципы разработки Культура кодирования Дублирование кода в программе строго запрещается.
Не применяйте функциональную декомпозицию. Для повторного использования кода применяйте средства ООП, например, наследование;
Обязательна замена числовых и строковых литералов символическими константами. Исключение можно сделать для самоочевидных констант, таких как 0 и 1. Давайте символическим константам значимые имена;
Рекомендуется объединять связанные между собой константы целых типов в перечислители, а не целых типов – в абстрактные классы с открытыми статическими константными членами;
Разделяйте общеупотребительные константы, перечислители и вспомогательные классы посредством System Frameworks проектов;
Максимально следуйте практике ООД/ООП. Максимально используйте шаблоны проектирования, но делайте это в правильном контексте, как это описано в секции “Applicability” данного шаблона;
Избегайте длинных и сложных методов, разбивайте их на несколько коротких. При модификации кода максимально используйте рефакторинг;
Всегда обращайте внимание на предупреждения компилятора.
Добивайтесь, чтобы их не было.
Соглашения о комментариях Код должен легко читаться и без комментариев. Выражайте свои мысли при помощи алгоритмического языка, а не английского или украинского;
Текст комментария отделяйте от слэшей одним пробелом.
Первая буква предложения должна быть прописной, в конце предложения должна стоять точка;
// This is a sample comment. This is yet another comment sentence.
Комментарии должны подчиняться общим правилам сворачивания строк.
Комментарии к методам, свойствам, классам, интерфейсам и другим конструкциям языка должны иметь XML-формат для возможной генерации программных документов в дальнейшем;
Не используйте комментарии в стиле C: /* … */ Комментарий не должен перефразировать то, что написано в коде. Старайтесь давать содержательные пояснения. Например, комментарий “Increment i by one” к коду “i++;” это плохая практика, а комментарий “Update the number of customer accounts processed” – хорошая.
Специфика Windows Forms Следуйте Microsoft User Interface Guidelines, если к вам не предъявляют других требований.
Если два управляющих элемента служат одной цели (например, поле ввода для имени пользователя и метка перед ним), разрешается использовать тип элемента в окончании имени. Для предыдущего примера это могут быть имена “customerNameText” и “customerNameLabel” соответственно.
Старайтесь убирать всю бизнес-логику из форм и управляющих элементов. В обработчики событий элементов помещайте только вызовы методов;
Используйте нотацию «верблюд» для наименования экземпляров управляющих элементов на формах и пользовательских управляющих элементах, например, “optionsHeading”;
Используйте нотацию «Паскаль» для наименования классов форм и управляющих элементов, например, “ ProductList ”;
Стремитесь к повторному использованию UI и исходного кода. Делите ваш интерфейс на элементы; смело наследуйте формы и управляющие элементы.
Источник информации http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpgenref/html/cpconnetframeworkdesignguidelines.asp
