![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
DEFAULT_SCALE ⇐ ПредыдущаяСтр 9 из 9
- 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
|