DEFAULT_SCALE

- correctionFactor;

Длинный список параметров метода также должен быть свернут, равно как и список аргументов в инструкции вызова метода:

// 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 и исходного кода. Делите ваш интерфейс на элементы; смело наследуйте формы и управляющие элементы.

Источник информации https://msdn.microsoft.com/library/default.asp? url=/library/enus/cpgenref/html/cpconnetframeworkdesignguidelines.asp