Стэнфордский университет представил гайд по основным стандартам оформления кода на С++. Умение корректно оформить ваш код является ценным навыком, так как это в разы облегчает работу других. Также у нас есть подобная статья, посвящённая написанию самодокументируемого кода.
Пробелы и отступы
Отделяйте пробелами фигурные скобки:
Ставьте пробелы между операторами и операндами:
Когда строка становится длиннее 100 символов, разделите её на две, сделав перевод на новую строку после оператора, и продолжайте писать:
Оставляйте пустые линии между функциями и между группами выражений:
Названия и переменные
Давайте переменным описательные имена, такие как firstName или homeworkScore . Избегайте однобуквенных названий вроде x или c , за исключением итераторов вроде i .
Называйте переменные и функции, используя верблюжийРегистр . Называйте классы ПаскальнымРегистром , а константы — в ВЕРХНЕМ_РЕГИСТРЕ . Узнать подробнее про верблюжий регистр вы можете в этой статье.
Если переменная используется лишь внутри определенного if , то делайте её локальной, объявляя в том же блоке кода, а не глобальной.
«Росбанк», Москва, до 60 000 ₽ (до налогов)
Выбирайте подходящий тип данных для ваших переменных. Если переменная содержит лишь целые числа, то определяйте её как int , а не double .
Используйте текстовую строку, стандартную для C++, а не С. С++ путает тем, что имеет два вида текстовых строк: класс string из С++ и старый char* (массив символов) из С:
Если определенная константа часто используется в вашем коде, то обозначьте её как const и всегда ссылайтесь на данную константу, а не на её значение:
Никогда не объявляйте изменяемую глобальную переменную. Глобальными переменными должны быть только константы. Вместо того, чтобы делать значение глобальным, сделайте его параметром и возвращайте значение, когда необходимо:
Базовые выражения С++
С++ основан на С, поэтому всегда есть вариант решить задачу «путем С++» и «путем С». Например, когда вы желаете вывести что-либо на системную консоль, вы можете сделать это «путем С++» , использовав оператор вывода cout , в то время как «путем С» вы бы использовали глобальную функцию вроде printf :
Частенько затрудняетесь с выбором между for и while ? Используйте цикл for , когда вы знаете количество повторений, а цикл while , когда количество повторений неизвестно:
Когда используете операторы управления вроде if / else , for , while , всегда используйте < >и соответствующие отступы, даже если тело всего оператора управления состоит лишь из одной строки:
Старайтесь избегать использования выражений break или continue . Используйте их только в том случае, если это абсолютно необходимо.
В C++ есть функция exit , которая немедленно завершает программу. Настоятельно не рекомендуется использовать данную функцию. Программа всегда должна заканчиваться естественно, достигая оператора return функции main .
Используя выражения if / else , подобающе выбирайте между разнообразными if и else шаблонами в зависимости от условий, относящихся к друг другу. Избегайте излишних тестов if :
Если у вас есть выражение if / else , которое возвращает логическое значение, возвращайте результаты теста напрямую:
Никогда не проверяйте значения логического типа, используя == или != с true или false :
Чрезмерность
Если вы используете один и тот же код дважды или более, то найдите способ удалить излишний код, чтобы он не повторялся. К примеру, его можно поместить во вспомогательную функцию. Если повторяемый код похож, но не совсем, то постарайтесь сделать вспомогательную функцию, которая принимает параметры и представляет разнящуюся часть:
Переместите общий код из выражения if / else , чтобы он не повторялся:
Комментарии
Заглавный комментарий. Размещайте заглавный комментарий, который описывает назначение файла, вверху каждого файла. Предположите, что читатель вашего комментария является продвинутым программистом, но не кем-то, кто уже видел ваш код ранее.
Заголовок функции / конструктора. Разместите заголовочный комментарий на каждом конструкторе и функции вашего файла. Заголовок должен описывать поведение и / или цель функции.
Параметры / возврат. Если ваша функцию принимает параметры, то кратко опишите их цель и смысл. Если ваша функция возвращает значение — кратко опишите, что она возвращает.
Исключения. Если ваша функция намеренно выдает какие-то исключения для определенных ошибочных случаев, то это требует упоминания.
Комментарии на одной строке. Если внутри функции имеется секция кода, которая длинна, сложна или непонятна, то кратко опишите её назначение.
TODO. Следует удалить все // TODO комментарии перед тем, как заканчивать и сдавать программу.
Эффективность
Вызывая большую функцию и используя результат несколько раз, сохраните результат в переменной вместо того, чтобы постоянно вызывать данную функцию:
Функции и процедурное проектирование
Хорошо спроектированная функция имеет следующие характеристики:
- Полностью выполняет четко поставленную задачу;
- Не берет на себя слишком много работы;
- Не связана с другими функциями бесцельно;
- Хранит данные максимально сжато;
- Помогает распознать и разделить структуру программы;
- Помогает избавиться от излишков, которые иначе присутствовали бы в программе.
Используйте параметры, чтобы отправлять информацию из функции или когда функции нужно возвратить несколько значений. Не используйте параметры без необходимости. Заметьте, что a , b , и с не являются параметрами в нижеприведенной функции, так как это не нужно:
Когда требуется вернуть значение из функции, используйте значение return :
Отправляя объект в функцию как параметр, вы должны передавать его по ссылке, так как если он будет передан как значение, то будет скопирован весь объект. Копирование объектов требует больших затрат памяти.
Используйте ссылочные переменные, а не указатели. Одна из причин — это то, что ссылочные переменные, в отличие от указателей, не могут принимать значение NULL :
Если вы передаете объект в функцию и код не изменит вида объекта — передайте его как const -ссылку:
Избегайте “цепных” вызовов, когда множество функций вызывают друг друга по цепочке, не возвращая значение в main . Убедитесь, что main является кратким описанием всей программы:
Проектирование классов
Инкапсуляция. Отделяйте ваши объекты, делая все поля данных в вашем классе private :
.h vs .cpp. Всегда размещайте объявления классов и их частей в собственные файлы, ClassName.h . Всегда сворачивайте файлы объявления классов .h в блок препроцессоров #ifndef / define / endif , чтобы избежать множественных объявлений одного класса:
class vs struct. Всегда используйте class , только если вы не создаете очень маленький и простой вид данных, для которого нужны лишь несколько публичных переменных и, возможно, конструктор для их инициализации.
Избегайте ненужных полей. Используйте поля, чтобы хранить важные данные о ваших объектах, но не временные значения, которые используются единожды.
Соглашения о написании кода предназначены для реализации следующих целей. Coding conventions serve the following purposes:
Создание согласованного вида кода, позволяющего читателям сосредоточиться на содержимом, а не на структуре. They create a consistent look to the code, so that readers can focus on content, not layout.
Предоставление читателям возможности делать предположения, основанные на опыте, и поэтому быстрее понимать код. They enable readers to understand the code more quickly by making assumptions based on previous experience.
Упрощение процессов копирования, изменения и обслуживания кода. They facilitate copying, changing, and maintaining the code.
Предоставление лучших методик C#. They demonstrate C# best practices.
Майкрософт использует приведенные в этом разделе рекомендации для разработки примеров и документации. The guidelines in this topic are used by Microsoft to develop samples and documentation.
Соглашения об именах Naming Conventions
В коротких примерах, не содержащих директив using, рекомендуется использовать полные указания для пространства имен. In short examples that do not include using directives, use namespace qualifications. Если известно, что пространство имен импортировано в проект по умолчанию, не требуется указывать полные имена из этого пространства имен. If you know that a namespace is imported by default in a project, you do not have to fully qualify the names from that namespace. Полные имена, если они слишком длинные для одной строки, можно разбить после точки (.), как показано в следующем примере. Qualified names can be broken after a dot (.) if they are too long for a single line, as shown in the following example.
Нет необходимости изменять имена объектов, созданных с помощью инструментов разработки Visual Studio, чтобы привести их в соответствие с другими соглашениями. You do not have to change the names of objects that were created by using the Visual Studio designer tools to make them fit other guidelines.
Соглашения о расположении Layout Conventions
Чтобы выделить структуру кода и облегчить чтение кода, в хорошем макете используется форматирование. Good layout uses formatting to emphasize the structure of your code and to make the code easier to read. Примеры и образцы корпорации Майкрософт соответствуют следующим соглашениям. Microsoft examples and samples conform to the following conventions:
Использование параметров редактора кода по умолчанию (логичные отступы, отступы по четыре символа, использование пробелов для табуляции). Use the default Code Editor settings (smart indenting, four-character indents, tabs saved as spaces). Дополнительные сведения см. в разделе "Параметры", "Текстовый редактор", C#, "Форматирование". For more information, see Options, Text Editor, C#, Formatting.
Запись только одного оператора в строке. Write only one statement per line.
Запись только одного объявления в строке. Write only one declaration per line.
Если отступ для дополнительных строк не ставится автоматически, необходимо сделать для них отступ на одну позицию табуляции (четыре пробела). If continuation lines are not indented automatically, indent them one tab stop (four spaces).
Добавление по крайней мере одной пустой строки между определениями методов и свойств. Add at least one blank line between method definitions and property definitions.
Использование скобок для ясности предложений в выражениях, как показано в следующем коде. Use parentheses to make clauses in an expression apparent, as shown in the following code.
Соглашения о комментариях Commenting Conventions
Комментарий размещается на отдельной строке, а не в конце строки кода. Place the comment on a separate line, not at the end of a line of code.
Текст комментария начинается с заглавной буквы. Begin comment text with an uppercase letter.
Текст комментария завершается точкой. End comment text with a period.
Между разделителем комментария (/ /) и текстом комментария вставляется один пробел, как показано в следующем примере. Insert one space between the comment delimiter (//) and the comment text, as shown in the following example.
Вокруг комментариев не должно быть звездочек. Do not create formatted blocks of asterisks around comments.
Рекомендации по работе с языком Language Guidelines
В следующих подразделах описаны методики, которыми руководствуется команда C# для подготовки примеров и образцов кода. The following sections describe practices that the C# team follows to prepare code examples and samples.
Тип данных String String Data Type
Для сцепления коротких строк рекомендуется использовать интерполяцию строк, как показано в следующем коде. Use string interpolation to concatenate short strings, as shown in the following code.
Для добавления строк в циклы, особенно при работе с текстами больших размеров, рекомендуется использовать объект StringBuilder. To append strings in loops, especially when you are working with large amounts of text, use a StringBuilder object.
Неявно типизированные локальные переменные Implicitly Typed Local Variables
В случаях, когда тип переменной понятен из правой части назначения или когда точный тип не важен, рекомендуется использовать неявное типизирование для локальных переменных. Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important.
Если тип из правой части назначения не является очевидным, не рекомендуется использовать var. Do not use var when the type is not apparent from the right side of the assignment.
При указании типа переменной не следует полагаться на имя переменной. Do not rely on the variable name to specify the type of the variable. Имя может быть неверным. It might not be correct.
Рекомендуется избегать использования var вместо dynamic. Avoid the use of var in place of dynamic.
Рекомендуется использовать неявное типизирование для определения типа переменной цикла в циклах for и foreach. Use implicit typing to determine the type of the loop variable in for and foreach loops.
В следующем примере неявное типизирование используется в операторе for . The following example uses implicit typing in a for statement.
В следующем примере неявное типизирование используется в операторе foreach . The following example uses implicit typing in a foreach statement.
Беззнаковый тип данных Unsigned Data Type
- Как правило, рекомендуется использовать int вместо беззнаковых типов. In general, use int rather than unsigned types. В C# обычно используется int . Использование int упрощает взаимодействие с другими библиотеками. The use of int is common throughout C#, and it is easier to interact with other libraries when you use int .
Массивы Arrays
При инициализации массивов в строке объявления рекомендуется использовать сокращенный синтаксис. Use the concise syntax when you initialize arrays on the declaration line.
Делегаты Delegates
Для создания экземпляров типа делегата рекомендуется использовать сокращенный синтаксис. Use the concise syntax to create instances of a delegate type.
Операторы try-catch и using в процессе обработки исключений try-catch and using Statements in Exception Handling
Рекомендуется использовать оператор try-catch для обработки большей части исключений. Use a try-catch statement for most exception handling.
Использование оператора C# using упрощает код. Simplify your code by using the C# using statement. При наличии оператора try-finally, код которого в блоке finally содержит только вызов метода Dispose, вместо него рекомендуется использовать оператор using . If you have a try-finally statement in which the only code in the finally block is a call to the Dispose method, use a using statement instead.
Операторы && и || && and || Operators
Чтобы избежать возникновения исключений и увеличить производительность за счет пропуска необязательных сравнений, рекомендуется использовать && вместо & и || вместо | при выполнении сравнений, как показано в следующем примере. To avoid exceptions and increase performance by skipping unnecessary comparisons, use && instead of & and || instead of | when you perform comparisons, as shown in the following example.
Оператор New New Operator
Рекомендуется использовать сокращенную форму создания экземпляра для объекта с неявным типизированием, как показано в следующем объявлении. Use the concise form of object instantiation, with implicit typing, as shown in the following declaration.
Предыдущая строка соответствует следующему объявлению. The previous line is equivalent to the following declaration.
Рекомендуется использовать инициализаторы объектов для упрощения создания объектов. Use object initializers to simplify object creation.
Обработка событий Event Handling
При определении обработчика событий, которого не требуется удалять позднее, рекомендуется использовать лямбда-выражение. If you are defining an event handler that you do not need to remove later, use a lambda expression.
Статический члены Static Members
- Для вызова статических членов следует использовать имя класса: ClassName.StaticMember. Call static members by using the class name: ClassName.StaticMember. В этом случае код становится более удобочитаемым за счет четкого доступа. This practice makes code more readable by making static access clear. Не присваивайте статическому члену, определенному в базовом классе, имя производного класса. Do not qualify a static member defined in a base class with the name of a derived class. Во время компиляции кода его читаемость нарушается, и если добавить статический член с тем же именем в производный классе, код может быть поврежден. While that code compiles, the code readability is misleading, and the code may break in the future if you add a static member with the same name to the derived class.
Запросы LINQ LINQ Queries
Используйте значимые имена для переменных запроса. Use meaningful names for query variables. В следующем примере используется seattleCustomers для клиентов, находящихся в Сиэтле. The following example uses seattleCustomers for customers who are located in Seattle.
Рекомендуется использовать псевдонимы для уверенности в том, что в именах свойств анонимных типов верно используются прописные буквы при помощи правил использования прописных и строчных букв языка Pascal. Use aliases to make sure that property names of anonymous types are correctly capitalized, using Pascal casing.
Переименуйте свойства, если имена свойств в результате могут быть неоднозначными. Rename properties when the property names in the result would be ambiguous. Например, если запрос возвращает имя клиента и идентификатор распространителя, не оставляйте имена в виде Name и ID , а переименуйте их, чтобы было ясно, что Name — имя клиента и ID — идентификатор распространителя. For example, if your query returns a customer name and a distributor ID, instead of leaving them as Name and ID in the result, rename them to clarify that Name is the name of a customer, and ID is the ID of a distributor.
Рекомендуется использовать неявное типизирование в объявлении переменных запроса и переменных диапазона. Use implicit typing in the declaration of query variables and range variables.
Выравнивайте предложения запроса под предложением from, как показано в предыдущих примерах. Align query clauses under the from clause, as shown in the previous examples.
Чтобы гарантировать, что более поздние предложения запроса работают с ограниченным, отфильтрованным набором данных, используйте предложение where перед другими предложениями запроса. Use where clauses before other query clauses to ensure that later query clauses operate on the reduced, filtered set of data.
Используйте несколько предложений from для доступа к внутренним коллекциям вместо предложения join. Use multiple from clauses instead of a join clause to access inner collections. Например, коллекция объектов Student может содержать коллекцию результатов тестирования. For example, a collection of Student objects might each contain a collection of test scores. При выполнении следующего запроса возвращаются результаты, превышающие 90 балов, а также фамилии учащихся, получивших такие оценки. When the following query is executed, it returns each score that is over 90, along with the last name of the student who received the score.
Безопасность Security
Следуйте указаниям, изложенным в правилах написания безопасного кода. Follow the guidelines in Secure Coding Guidelines.
руководитель проектного офиса, руководитель проектов
среда, 12 января 2011 г. — www.msmirnov.ru
Стандарты и правила оформления кода C#
Последнее время меня несколько раз спрашивали относительно стандартов и правил оформления кода C#, поэтому я решил выложить их в открытый доступ.
Для загрузки Стандарты и правила доступны по следующей ссылке на моем сайте: http://www.msmirnov.ru/public/TSQL_Coding_Standards.doc
Либо с ними можно ознакомиться прямо здесь.
- предоставить общие правила, позволяющие сохранить единый стиль написания кода, облегчив тем самым его понимание всеми участниками команды;
- ввести базовые правила написания программ, что позволит повысить предсказуемость выполнения программ, а также избежать ошибок при написании программ новыми участниками команды, не знакомыми с внутренними стандартами разработки.
- Camel case – первая буква первого слова в идентификаторе в нижнем регистре, все первые буквы последующих слов – в верхнем.
- UpperCase – стиль используется только для сокращений, все буквы в имени идентификатора в верхнем регистре.
- Hungarian notation – перед именем идентификатора пишется его тип в сокращенной форме.
Общие правила именования идентификаторов
- При именовании идентификаторов не используются аббревиатуры или сокращения, если только они не являются общепринятыми.
- Если имя идентификатора включает в себя сокращение – сокращение пишется в upper case . Исключение — когда имя идентификатора должно быть указано в camel case и сокращение стоит в начале имени идентификатора. В этом случае сокращение пишется в нижнем регистре.
Использование верхнего и нижнего регистра в именах
Пример:
Keyword M anager и Keyword m anager;
KeywordManager. Keyword и KeywordManager. KEYWORD ;
int id и int ID ;
f indByID(int id) и F indByID(int id);
void MyFunction(string s , string S ).
Правила именования классов
- Для классов используется стиль именования pascal case ;
- Для классов, унаследованных от CollectionBase используется суффикс Collection , перед которым указывается тип объектов, для которых используется коллекция.
- В качестве имен классов используются имена существительные;
- Имя класса не должно совпадать с именем namespace ’ а.
- Если класс представляет собой сущность, хранимую в базе данных – имя класса соответствует имени таблицы. В этом случае имя класса – это название сущности в единственном числе, имя таблицы – во множественном числе.
- При создании классов потомков их имена состоят из имени базового класса и суффикса класса потомка, если суффиксов несколько – они разделяются символом подчеркивания.
- Имена файлов, в которых находятся классы, совпадают с именами классов. Для именования файлов используется стиль pascal case .
Правила именования интерфейсов
Правила именования generic ’ ов
Правила именования функций
- Функции объявляются согласно следующему шаблону:
- Имена функций должны давать четкое представление о том, какое действие эта функция выполняет. Имя функции начинается с глагола, указывающего на то, какое действие она выполняет;
- Большие функции, не умещающиеся на одном экране, делятся на несколько private функций меньшего размера, имена таких вспомогательных функций состоят из имени основной (большой) функции и существительного, глагола или фразы, которые уточняют действие вспомогательной функций, разделенные подчеркиванием. Основная и вспомогательная функции объединяются в регионы. Вспомогательные функции вызываются только из основной функции.
Правила именования параметров функций
- Для именования параметров используется стиль camel case ;
- Имена параметров должны давать четкое представление о том для чего используется параметр, и какое значение следует передать при вызове функции.
- В том случае, когда это не препятствует понимаю кода, в качестве имени параметра функции используется имя соответствующего параметру класса. Для коллекций и массивов используется имя объектов, содержащихся в коллекции или массиве.
- Имена параметров не должны совпадать с именами членов класса, если этого не удается избежать, то для разрешения конфликтов используется ключевое слово this .
- В именах параметров не используется венгерская нотация.
Правила именования свойств
- Свойства объявляются согласно следующему шаблону:
- В том случае, когда это не препятствует понимаю кода, в качестве имени свойства используется имя соответствующего свойству класса. Для коллекций и массивов используется имя объектов, содержащихся в коллекции или массиве.
- Название свойства типа bool должно представлять из себя вопрос, требующий ответа да или нет.
Правила именования полей
- Название поля типа bool должно представлять из себя вопрос, требующий ответа да или нет.
Правила именования переменных
- Переменные объявляются согласно следующему шаблону:
- В циклах foreach имя переменной назначается как имя массива в единственном числе.
Правила именования констант
- Для именования констант используется стиль pascal case .
Правила именования enum ’ ов
Правила именования exception ’ ов
Правила именования control ’ ов в asp.net
- Если set или get свойства состоит из одной операции – весь set или get размещается на одной строке.
- Функции, поля и свойства группируются внутри класса по своему назначению. Такие группы объединяются в регионы;
и .
- Для функций, выполняющих сложные алгоритмы, не очевидные для восприятия, необходимо указывать подробные комментарии не только к заголовку функции, но и самому алгоритму с пояснением каждого шага выполнения алгоритма;
- В случае внесения изменений в критические участки кода, ядро системы, либо когда сложно проследить последствия, которые может повлечь такое изменение, необходимо указывать подробный комментарий о том кто внес изменение, когда и по какой причине;
- В том случае если необходимо временно добавить заплатку, без которой система не может работать, но заплатку в дальнейшем планируется убрать – необходимо добавлять ключевое слово “ //TODO: ”, после которого указывается когда и что должно быть исправлено. Кроме этого необходимо указывать подробный комментарий о том, для чего предназначено временное исправление, кто его внес и когда;
- При разработке кода, изменения которого могут повлечь за собой сбой в других частях системы, при этом связь между этими двумя частями программы неочевидна и ошибка не будет показана на этапе компиляции, либо если сам код неочевидным образом зависит от других частей системы – необходимо указывать подробное описания взаимосвязей.
- В конфигурационном файле ключи необходимо группировать по назначению. Перед началом каждой такой группы в комментариях необходимо указывать открывающий tag с названием группы, в конце – закрывающий tag .
- Для ключей, хранящих boolean значения, value может быть равно только true или false , а не 0/1 или yes/no .
- Модификаторы доступа необходимо указывать всегда. Не смотря на то, что по умолчанию назначается модификатор доступа private , поле модификатора не остается пустым – модификатор private необходимо указывать явным образом.
- Модификаторы доступа ( private, protected, internal и public ) необходимо указывать в зависимости от того, где требуется доступность соответствующего поля, свойства, функции, класса или конструктора. Модификатор public необходимо указывать только тогда, когда необходим доступ к полю из других проектов, internal – когда необходим доступ из других классов внутри одного проекта, protected – для предоставления доступа классам – потомкам, во всех остальных случаях используется private , т.е. доступ ограничивается самим классом;
- Поля и переменные инициализируются при их объявлении, когда это возможно.
- Когда для создания класса необходимо передать параметры, используемые при его инициализации, на конструктор по умолчанию (MyClass() < >) необходимо накладывать модификатор доступа private, чтобы избежать создания клиентами неинициализированного объекта.
- Вместо использования “magic numbers” для идентификаторов статусов, состояний и т.п. необходимо указывать константы или enum ’ ы. Идентификаторы состояний в виде чисел использовать нельзя.
- Тип object необходимо использовать только когда это действительно необходимо, в большинстве случаев вместо него используются generic ’ и. Вместо Hashtable необходимо использовать Dictionary<>, вместо ArrayList используется List<>;
- В том случае если в get ’ е или set ’ е какого-либо свойства выполняются сложные вычисления, если операция, выполняемая в get или set является преобразованием, имеет побочный эффект или долго выполняется – свойство должно быть заменено функциями;
- Свойство не должно менять своего значения от вызова к вызову, если состояние объекта не изменяется. Если результат при новом вызове может быть другим при том же состоянии объекта, вместо свойства необходимо использовать функции;
- Внутри get ’ а и set ’ а не должно быть обращений к коду, не связанному напрямую с получением или сохранением значения свойства, т.к. такие действия могут быть не очевидны для клиентов, использующих свойство;
- Все настройки, влияющие на работу приложения, нельзя указывать жестко в коде, а необходимо выносить в config. Если есть возможность прописать значение по умолчанию – они должны быть прописаны, если значение по умолчанию не может быть задано и соответствующий ключ не прописан в конфиге – необходимо создавать исключение.
- Button – btn,
- CheckBox – cb,
- DropDownList – ddl,
- HiddenField – hf,
- HyperLink – hl,
- Image – img,
- ImageButton – ibtn
- Label – l,
- LinkButton – lbtn
- ListBox – lb,
- Literal – lt,
- Panel – pnl
- PlaceHolder – ph,
- RadioButton – rb,
- TextBox – tb,
- Table – tbl,
- Validator – val,
- ValidationSummary – vals,
- AdRotator – ar,
- BulletList – bl,
- Calendar – cld,
- CheckBoxList – cbl,
- FileUpload – fup,
- ImageMap – im,
- Localize – loc,
- MultiView – mv,
- RadioButtonList – rbl,
- Substitution – sbs
- View – v,
- Wizard – wiz,
- Xml – xml.
