Используют ли люди венгерские соглашения об именах в реальном мире?

Стоит ли изучать конвенцию или это плохо для удобочитаемости и ремонтопригодности?

Ответов (20)

Решение

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

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

Если вы читали статью Википедии на эту тему, вы найдете две противоречащие друг другу нотации, Системы венгерской нотации и Apps венгерскую нотацию .

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

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

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

int vBox = aBottom * lVerticalSide;

но это не так:

int aBottom = lSide1;

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

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

int iLength;
int iVolume;
int iArea;

некоторые люди используют n для числа или i для целого числа, f для числа с плавающей запятой, s для строки и т. д.

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

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


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

Что не так, это стандарты смешивания.

Правильно делать так, чтобы все делали одно и то же.

int Box = iBottom * nVerticleSide

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

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

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

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

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

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

Прочтите статью Джоэла Спольски «Как сделать неправильный код неправильным», чтобы получить соответствующую точку зрения и обоснование.

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

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

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

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

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

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

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

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

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

Такие вещи , как sValue, iCount, dAmount или fAmount, и bFlag везде.

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

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

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

int vBox = aBottom * lVerticalSide;

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

int boxVolume = bottomArea * verticalHeight;

На дворе 2008 год. У нас больше нет 80-символьных экранов с фиксированной шириной!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разве в наши дни объем более важен, чем тип, например

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

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

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

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

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

Их можно комбинировать, поэтому статическая переменная-член, которая является указателем, будет «mspName».

Где это полезно?

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

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

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