Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Замечание
Это содержимое перепечатывается разрешением Pearson Education, Inc. из руководства по проектированию платформы: соглашения, идиомы и шаблоны для повторно используемых библиотек .NET, 2-го выпуска. Этот выпуск был опубликован в 2008 году, и книга с тех пор была полностью пересмотрена в третьем выпуске. Некоторые сведения на этой странице могут быть устаревшими.
В этом разделе описываются общие соглашения об именовании, относящиеся к выбору слов, рекомендации по использованию сокращенных и акронимов, а также рекомендации по предотвращению использования имен, относящихся к языку.
Выбор слова
✔️ Выберите легко читаемые имена идентификаторов.
Например, свойство с именем HorizontalAlignment является более читаемым на английском языке, чем AlignmentHorizontal.
✔️ Следует предпочитать удобочитаемость важнее краткости.
Название свойства CanScrollHorizontally лучше, чем ScrollableX (туманная ссылка на ось X).
❌ НЕ используйте символы подчеркивания, дефисы или другие нефалумерные символы.
❌ НЕ используйте венгерскую нотацию.
❌ Избегайте использования идентификаторов, конфликтующих с ключевыми словами широко используемых языков программирования.
Согласно правилу 4 спецификации CLS, все соответствующие языки должны предоставлять механизм, позволяющий получить доступ к именованным элементам, используюющим ключевое слово этого языка в качестве идентификатора. Например, C# использует знак @ в качестве механизма экранирования в данном случае. Тем не менее, рекомендуется избежать распространенных ключевых слов, так как гораздо сложнее использовать метод с escape-последовательностью, чем один без него.
Использование аббревиаций и акронимов
❌ НЕ используйте аббревиатуры или сокращения в составе имен идентификаторов.
Например, используйте GetWindow вместо GetWinэтого.
❌ НЕ используйте любые акронимы, которые не принимаются широко, и даже если они есть, только при необходимости.
Избегайте имен Language-Specific
✔️ Используйте семантические интересные имена, а не ключевые слова, относящиеся к языку, для имен типов.
Например, GetLength лучшее имя, чем GetInt.
✔️ Используйте универсальное имя типа CLR, а не имя конкретного языка, в редких случаях, когда идентификатор не имеет семантического значения за его типом.
Например, метод, преобразующий в Int64, должен называться ToInt64, а не ToLong (поскольку Int64 является именем CLR для C#-специфичного псевдонима long C#). В следующей таблице представлены несколько базовых типов данных, используя имена типов CLR (а также соответствующие имена типов для C#, Visual Basic и C++).
| C# | Visual Basic | C++ | Среда выполнения CLR |
|---|---|---|---|
| знаковый байт | SByte | символ | SByte |
| байт | Байт | беззнаковый char | Байт |
| короткий | короткий | короткий | Int16 |
| ushort | UInt16 | беззнаковый короткий | UInt16 |
| int | Целое число | int | Инт32 |
| uint | УИнт32 | unsigned int | УИнт32 |
| длинный | Длинный | __int64 | Int64 |
| ulong | УИнт64 | без знака __int64 | УИнт64 |
| плавать | Один | плавать | Один |
| двойной | Двойной | двойной | Двойной |
| bool | Булев | bool | Булев |
| символ | Уголь | wchar_t | Уголь |
| строка | Струна | Струна | Струна |
| объекта | Объект | Объект | Объект |
✔️ Используйте общее имя, например value или item, вместо повторения имени типа, в редких случаях, когда идентификатор не имеет семантического значения, а тип параметра не важен.
Именование новых версий существующих API
✔️ При создании новых версий существующего API используйте имя, аналогичное старому API.
Это помогает подчеркнуть взаимосвязь между API.
✔️ Do предпочитает добавлять суффикс, а не префикс, чтобы указать новую версию существующего API.
Это поможет обнаружить при просмотре документации или использовании IntelliSense. Старая версия API будет организована близко к новым API, так как большинство браузеров и IntelliSense отображают идентификаторы в алфавитном порядке.
✔️ Рекомендуется использовать новый, но значимый идентификатор вместо добавления суффикса или префикса.
✔️ Используйте числовый суффикс, чтобы указать новую версию существующего API, особенно если существующее имя API является единственным именем, которое имеет смысл (т. е. если это отраслевый стандарт), и если добавить какой-либо значимый суффикс (или изменить имя) не является подходящим вариантом.
❌ Не используйте суффикс Ex (или аналогичный) для идентификатора, чтобы отличить его от более ранней версии того же API.
✔️ Используйте суффикс "64" при вводе версий API, которые работают с 64-разрядным целым числом (длинным целым числом) вместо 32-разрядного целого числа. Этот подход необходимо применять только в том случае, если существует 32-разрядный API; не используйте его для совершенно новых API, которые существуют только в 64-разрядной версии.
© Часть 2005, 2009 Корпорация Майкрософт. Все права защищены.
Перепечатан с разрешения Pearson Education, Inc. из Руководство по проектированию: Соглашения, идиомы и шаблоны для повторного использования библиотек .NET, 2-е издание Кшиштоф Чвалина и Брэд Абрамс, опубликованное 22 октября 2008 года Addison-Wesley Профессиональный в рамках серии разработки Microsoft Windows.