Используют ли венгерские конвенции о присвоении имен в реальном мире?

Ответ 1

Учитывая, что большинство людей, использующих венгерскую нотацию, следуют непонятной версии этого, я бы сказал, что это довольно бессмысленно.

Если вы хотите использовать исходное определение, это может иметь больше смысла, но кроме этого это в основном синтаксический сахар.

Если вы прочитали статью статьи Википедии по этому вопросу, вы найдете две противоречивые обозначения: Венгерская нотация системных вендоров и приложения.

Оригинальное, хорошее, определение - венгерское обозначение Apps, но большинство людей используют системные венгерские обозначения.

В качестве примера двух рассмотрим префиксные переменные с l для длины, a для области и v для объема.

С такими обозначениями имеет смысл следующее выражение:

int vBox = aBottom * lVerticalSide;

но это не так:

int aBottom = lSide1;

Если вы смешиваете префиксы, их следует рассматривать как часть уравнения, а length = area * length подходит для поля, но копирование значения длины в переменную области должно поднять некоторые красные флаги.

К сожалению, другие обозначения менее полезны, когда люди префиксные имена переменных имеют тип значения, например:

int iLength;
int iVolume;
int iArea;

некоторые люди используют n для числа или я для integer, f для float, s для строки и т.д.

Первоначальный префикс должен был использоваться для определения проблем в уравнениях, но каким-то образом он превратился в код, который немного легче читать, так как вам не нужно искать объявление переменной. С сегодняшними умными редакторами, где вы можете просто нависнуть над любой переменной, чтобы найти полный тип, а не просто аббревиатуру для этого, этот тип венгерской нотации потерял много смысла.

Но, ты должен составить свой собственный разум. Все, что я могу сказать, это то, что я тоже не использую.

Изменить. Чтобы добавить короткое уведомление, в то время как я не использую венгерскую нотацию, я использую префикс, и это подчеркивание. Я префикс всех частных полей классов с символом _ и в противном случае заклинаю их имена, поскольку я хотел бы иметь свойство, тэз с первой буквой в верхнем регистре.

Ответ 2

Венгерская конвенция о присвоении имен может быть полезна при правильном использовании, к сожалению, она чаще всего используется неправильно.

Прочитайте статью Джоэла Спольского Неправильный код неправильного кода для соответствующей перспективы и обоснования.

По существу, венгерская нотация на основе типа, где переменные имеют префикс информации об их типе (например, является ли объект строкой, дескриптором, int и т.д.), в основном бесполезны и обычно просто добавляют накладные расходы с очень небольшим преимуществом. К сожалению, это венгерская нотация, с которой знакомы большинство людей. Однако намерение венгерской нотации, как предполагается, состоит в том, чтобы добавить информацию о "вид" данных, которые содержит переменная. Это позволяет вам разделить виды данных от других видов данных, которые не должны смешиваться друг с другом, за исключением, возможно, процесса преобразования. Например, координаты на основе пикселов по сравнению с координатами в других единицах или небезопасные входные данные пользователя по сравнению с данными из безопасных источников и т.д.

Посмотрите на это таким образом, если вы обнаружите, что вы просматриваете код, чтобы узнать информацию о переменной, вам, вероятно, нужно будет настроить схему именования, чтобы содержать эту информацию, в этом суть венгерской конвенции.

Обратите внимание, что альтернативой венгерской нотации является использование большего количества классов, чтобы показать намерение использования переменных, а не полагаться на примитивные типы во всем мире. Например, вместо наличия префиксов переменных для небезопасного ввода пользователя вы можете иметь простой класс оболочки строки для небезопасного ввода пользователя и отдельный класс-оболочку для безопасных данных. Это имеет преимущество, на строго типизированных языках, из-за того, что секционирование выполняется компилятором (даже на менее строго типизированных языках вы обычно можете добавить свой собственный код tripwire), но добавляет незначительное количество накладных расходов.

Ответ 3

Я все еще использую венгерскую нотацию, когда речь идет о элементах пользовательского интерфейса, где несколько элементов пользовательского интерфейса связаны с конкретным объектом/значением, например,

lblFirstName для объекта метки, txtFirstName для текстового поля. Я определенно не могу назвать их обоих "FirstName", даже если это проблема/ответственность обоих объектов.

Как другие подходы к именованию элементов пользовательского интерфейса?

Ответ 4

Это бессмысленно (и отвлекает), но находится в относительно тяжелом использовании в моей компании, по крайней мере для таких типов, как ints, string, boolean и doubleles.

Вещи вроде sValue, iCount, dAmount или fAmount и bFlag.

Когда-то была хорошая причина для этого соглашения. Теперь это рак.

Ответ 5

Я думаю, что венгерская нотация - интересная сноска вдоль "пути" к более читаемому коду, и если все сделано правильно, предпочтительнее не делать этого.

Говоря это, я бы скорее покончил с этим, а вместо этого:

int vBox = aBottom * lVerticalSide;

напишите это:

int boxVolume = bottomArea * verticalHeight;

Это 2008. У нас больше нет экранов с фиксированной шириной 80 символов!

Кроме того, если вы пишете имена переменных, которые намного длиннее, чем вы должны смотреть на рефакторинг на объекты или функции в любом случае.

Ответ 6

Извините, что ответил на вопрос, но префиксные интерфейсы с "я" квалифицируются как венгерская нотация? Если это так, то да, многие люди используют его в реальном мире. Если нет, игнорируйте это.

Ответ 7

Я вижу венгерскую нотацию как способ обойти способность наших кратковременных воспоминаний. По мнению психологов, мы можем хранить примерно 7 плюс-минус 2 куска информации. Дополнительная информация, добавленная добавлением префикса, помогает нам, предоставляя более подробную информацию о значении идентификатора даже без другого контекста. Другими словами, мы можем догадаться, для чего нужна переменная, не видя, как она используется или объявляется. Этого можно избежать, применяя методы oo, такие как encapsulation и single принцип ответственности.

Я не знаю, было ли это изучено эмпирически. Я бы предположил, что количество усилий резко возрастает, когда мы пытаемся понять классы с более чем девятью переменными экземпляра или методами с более чем 9 локальными переменными.

Ответ 8

В настоящее время область не важна, чем тип, например

• l для локальных
• a для аргумента
• m для участника
• g для глобальных
• и т.д.

С современными методами рефакторинга старого кода поиск и замена символа, потому что вы изменили его тип, утомительно, компилятор будет улавливать изменения типа, но часто не будет ловить неправильное использование области, здесь разумные соглашения об именах помогают.

Ответ 9

Когда я вижу венгерскую дискуссию, я рад видеть, как люди много думают о том, как сделать свой код более ясным, и как ошибаться. Это то, что мы все должны делать!

Но не забывайте, что у вас есть несколько мощных инструментов, помимо вашего имени.

Метод извлечения. Если ваши методы становятся настолько длинными, что ваши объявления переменных прокручиваются в верхней части экрана, подумайте о том, чтобы ваши методы были меньше. (Если у вас слишком много методов, рассмотрите новый класс.)

Сильная типизация. Если вы обнаружите, что вы берете zip-коды, хранящиеся в целочисленной переменной, и назначая их целочисленной переменной размера обуви, подумайте о создании класса для почтовых индексов и класса для размера обуви. Тогда ваша ошибка будет обнаружена во время компиляции, вместо того, чтобы требовать тщательной проверки человеком. Когда я это делаю, я обычно нахожу кучу зависящей от почтового индекса и специфической для обуви логики, которую я надул вокруг своего кода, и затем я могу перейти к своим новым классам. Внезапно весь мой код становится яснее, проще и защищен от определенных классов ошибок. Ничего себе.

Подводя итог: да, задумайтесь над тем, как вы используете имена в коде, чтобы четко выражать свои идеи, но также смотрите на другие мощные инструменты OO, которые вы можете вызвать.

Ответ 10

Я не использую очень строгий смысл венгерской нотации, но я нахожу, что использую ее, экономя некоторые общие пользовательские объекты, чтобы помочь их идентифицировать, а также я склонен префикс gui-контрольных объектов с типом элемента управления, которым они находятся. Например, labelFirstName, textFirstName и buttonSubmit.

Ответ 11

Я работаю в IBM последние 6 месяцев, и я его нигде не видел (слава богу, потому что я его ненавижу). Я вижу либо camelCase, либо c_style.

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

Ответ 12

Я использую венгерское название для элементов пользовательского интерфейса, таких как кнопки, текстовые поля и таблицы. Основное преимущество заключается в группировке в Visual Studio Intellisense Popup. Если я хочу получить доступ к моим таблицам, я просто начну печатать lbl.... и Visual Studio предложит все мои таблицы, сгруппированные вместе.

Однако после того, как все больше и больше элементов Silverlight и WPF, используя привязку данных, я даже не называю все мои элементы управления, так как мне не нужно ссылаться на них с кода (поскольку на самом деле нет любой codebehind больше;)

Ответ 13

В чем неправильные стандарты смешивания.

Какое право заключается в том, чтобы все делали то же самое.

int Box = iBottom * nVerticleSide

Ответ 14

Первоначальный префикс должен был быть используется для определения проблем в уравнениях, но каким-то образом код немного легче читать, поскольку вам не нужно искать объявление переменной. С сегодняшним днем умных редакторов, где вы можете просто наведите указатель мыши на любую переменную, чтобы найти полный, а не только аббревиатура для этого, этот тип венгерская нотация потеряла много его значение.

Я немного нарушаю привычку, но префикс типа может быть полезен в JavaScript, который не имеет сильной переменной ввода.

Ответ 15

При использовании динамически типизированного языка я иногда пользуюсь Apps Hungarian. Для статически типизированных языков я этого не делаю. См. Мое объяснение в другом потоке.

Ответ 16

Венгерская нотация бессмысленна в языках с типом. например Общий префикс, который вы увидите в старом коде Microsoft, - "lpsz", что означает "длинный указатель на строку с нулевым завершением". С начала 1700 года мы не использовали сегментированные архитектуры, где существуют короткие и длинные указатели, нормальное строковое представление в С++ всегда имеет нулевое завершение, а компилятор является безопасным по типу, поэтому мы не будем применять нестроковые операции к строка. Поэтому ни одна из этих данных не имеет никакого реального использования программисту - это просто больше набрав.

Однако я использую аналогичную идею: префиксы, которые уточняют использование переменной. Основные из них:

• m = member
• c = const
• s = static
• v = volatile
• p = указатель (и pp = указатель на указатель и т.д.)
• я = индекс или итератор

Они могут быть объединены, поэтому статическая переменная-член, которая является указателем, будет "mspName".

Где они полезны?

• В тех случаях, когда использование имеет важное значение, рекомендуется постоянно напоминать программисту, что переменная (например,) изменчива или указатель
• Разрушение указателя, используемое для моей работы, пока я не использовал префикс p. Теперь очень легко узнать, когда у вас есть объект (оранжевый) указатель на объект (pOrange) или указатель на указатель на объект (ppOrange). Чтобы разыменовать объект, просто поставьте перед ним звездочку для каждого p в своем имени. Дело решено, не больше ошибок deref!
• В конструкторах обычно обнаруживается, что имя параметра идентично имени переменной-члена (например, размер). Я предпочитаю использовать "mSize = size;" чем "size = theSize" или "this.size = size". Это также намного безопаснее: я не случайно использую "size = 1" (установка параметра), когда я хотел сказать "mSize = 1" (установка члена)
• В циклах мои переменные итератора - это все значимые имена. Большинство программистов используют "i" или "index", а затем должны создавать новые бессмысленные имена ( "j", "index2" ), когда им нужен внутренний цикл. Я использую значащее имя с префиксом я (iHospital, iWard, iPatient), поэтому я всегда знаю, что итератор выполняет итерацию.
• В циклах вы можете смешать несколько связанных переменных, используя одно и то же базовое имя с разными префиксами: оранжевый оранжевый = pOrange [iOrange]; Это также означает, что вы не делаете ошибок индексации массива (pApple [i] выглядит нормально, но пишите его как pApple [iOrange], и ​​ошибка сразу очевидна).
• Многие программисты будут использовать мою систему, не зная ее: добавив длинный суффикс, например "Index" или "Ptr", нет веских оснований использовать более длинную форму, чем один символ IMHO, поэтому я использую "i" и "p". Меньше ввод текста, более последовательный, легче читать.

Это простая система, которая добавляет значимую и полезную информацию для кодирования и исключает возможность множества простых, но распространенных ошибок программирования.

Ответ 17

Это зависит от вашего языка и среды. Как правило, я бы не использовал его, если только среда разработки, в которой вы находитесь, затрудняет поиск типа переменной.

Существует также два разных типа венгерских обозначений. См. Статью Джоэля. Я не могу найти его (его имена точно не позволяют их легко найти), у кого есть ссылка на то, что я имею в виду?

Изменить: У Клин есть статья, которую я имею в виду в его сообщении.

Ответ 18

Оригинальная форма (правая венгерская нотация:)), где тип средства префикса (т.е. длина, количество) значения, хранящегося переменной, в порядке, но не обязательно во всех типах приложений.

Популярная форма (The Wrong Hungarian Notation), где префикс означает тип (String, int), бесполезна на большинстве современных языков программирования.

Особенно с бессмысленными именами, такими как strA. Я не могу понять, что мы используем бессмысленные имена с длинными префиксами, которые ничего не дают.

Ответ 19

Я использую систему на основе типа (Systems HN) для компонентов (например, editFirstName, lblStatus и т.д.), так как она делает работу над автозаполнением лучше.

Я иногда использую App HN для переменных, где информация типа недостаточно. Т.е. fpX указывает фиксированную фиксированную переменную (тип int, но ее нельзя смешивать и сопоставлять с int), rawInput для пользовательских строк, которые не были проверены и т.д.

Ответ 20

Будучи программистом PHP, где он очень слабо набирается, я не собираюсь его использовать. Однако иногда я буду идентифицировать что-то как массив или как объект в зависимости от размера системы и области действия переменной.