каково принятое соглашение о присвоении имен для интервала, строки, массива, списка, объекта, и т.д.
Компания я работаю на данный момент, использует соглашение о присвоении имен набора для их переменных C#, таких как iSomeName для интервала, sSomeName для строки, aSomeName для массивов, bSomeName для булевской переменной, dSomeName для даты и времени и так далее. Мой предыдущий работодатель не использовал меня, s, a, b и d префиксы и просто назвал переменные хорошим понятным именем. Мое впечатление - то, что эти префиксы потеряли благосклонность только что и от того, что я считал, это не современная тенденция. Это кажется прекрасным мне так или иначе, пока переменная является достаточно описательной для понимания то, что это делает, но я задавался вопросом, что теперешняя принятая практика для именования переменных?
8 ответов
Обычный совет при ответе на эти вопросы - быть последовательным в своем собственном кодексе и в рамках своих работодателей; Если ваш работодатель использует венгерскую нотацию, вам следует использовать ее, независимо от общепринятой практики.
Ну, многое зависит от языка, который вы используете. . camelCase или PascalCase или underscore_variables . Назвать их правильно / читабельно / понятно - это самое главное.
Относительно этого префикса (или венгерской нотации): он конкретно рассматривается в MSDN: Общие соглашения об именах в C # , статья:
{{1 }}[...]
Не используйте венгерскую нотацию.
Венгерская нотация - это практика включения префикса в идентификаторы для кодирования некоторых метаданных о параметре , таких как тип данных идентификатора .
[...]
Ваш нынешний работодатель использует Системную венгерскую нотацию
Я лично не вижу смысла в этом соглашении об именах, поскольку большинство сред разработки будут обеспечьте цветную подсветку синтаксиса и проверку переменных, чтобы вы могли легко определить тип. В худшем случае это сбивает с толку, так как вы можете изменить тип переменной, но не изменить «префикс» переменной:
double iCount = 0.0;
«Современный» и «популярный» способ сделать это - без венгерской нотации (i, s и т. Д.). Причина в том, что рефакторинг больше не является проблемой. Это означает, что, по сути, код меняется не только с течением времени, но и массово. Когда вы проводите рефакторинг вещей, венгерская нотация затрудняет выполнение должным образом, поскольку это, как правило, делается с помощью различных инструментов, а эти инструменты не знают всех пользовательских стандартов венгерской нотации.
Представьте, что у вас есть переменная-член iAge для объекта, который был целым числом. Что, если вы захотите изменить это значение с int на long , потому что этот возраст был в миллисекундах? Что ж, тогда вам также придется переименовать его в lAge сейчас. Изменить типы легко, и это можно автоматизировать, но «творческое стандартное именование» сделать гораздо труднее. И действительно, наличие i или l перед этой переменной Age - ДЕЙСТВИТЕЛЬНО ли это говорит вам что-нибудь еще о том, что делает код? Конечно, он сообщает вам тип данных, но наведите на него курсор в любой современной среде IDE, и он также сообщит вам тип данных.
Короче говоря, «современное предпочтение» - убедиться, что цель вашего кода легко подготовить. Такие тривиальные вещи, как типы данных в венгерской нотации, только смущают это.Код и так достаточно сложно читать - не делайте его хуже!
Современная общепринятая практика для C # - не использовать венгерскую нотацию. Вместо этого лучше всего использовать понятное и описательное имя переменной.
StyleCop часто используется для обеспечения соблюдения стандартов форматирования кода в C # и по умолчанию не поддерживает венгерскую нотацию, хотя допускает исключения через конфигурацию.
Да, венгерский больше не используется слишком часто, и я думаю, что предпочтительнее использовать значимые имена, которые не требуют пояснений.
Если вы хотите прочитать хорошую статью (может быть, отправьте ее большим парикам: P) об этом, ознакомьтесь с Взгляды Джоэла на «Уродливый код» и венгерскую нотацию , это хорошее объяснение почему была сделана венгерская нотация и как ее неправильно использовали в течение многих поколений.
Ваш предыдущий работодатель больше соответствовал нынешней практике. Префикс переменных с кодами в настоящее время не считается лучшей практикой . Вы должны делать это только время от времени, если это проясняет код, а обычно этого не происходит. Очевидная потребность в любом типе префикса должна рассматриваться как второстепенная Запах кода , указывающая на то, что текущая процедура, вероятно, слишком сложна. Лучше потратить время на улучшение кода, чем на добавление префиксов.
См. Венгерская нотация для истории этой практики. Версия под названием Apps венгерская нотация означает, что префикс помогает указать назначение переменной, а не ее тип. Время от времени это законно, но редко бывает необходимо. Более распространенная практика называется Системная венгерская нотация , где префикс указывает тип. Это (к счастью) становится все реже.
Не впадайте в депрессию, чтобы сделать это. Есть много худших практик, которые мы вынуждены применять. Если это так плохо, то вам повезло. И иметь некоторые стандарты (если они не сумасшедшие) лучше, чем отсутствие стандартов .
Вам нужно обратиться к Framework Design Guidelines, а именно к главе 3. Та же информация (без аннотаций для "предыстории") доступна онлайн.
Система именования, которую использует ваш нынешний работодатель, называется венгерской нотацией и больше не рекомендуется компанией Microsoft. (На самом деле, большинство мест больше не используют ее)
.