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

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

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

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

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

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

При такой нотации имеет смысл следующее выражение:

int vBox = aBottom * lVerticalSide;

но это не так:

int aBottom = lSide1;

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

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

int iLength;
int iVolume;
int iArea;

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

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

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

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

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

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

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

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

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

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

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

Как другие подходят к именованию элементов UI?

Это бессмысленно (и отвлекает), но в моей компании он довольно широко используется, по крайней мере, для таких типов, как ints, strings, Boolean и Double.

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

Когда-то давным-давно была веская причина для этой конвенции. Так вот, это рак.

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

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

int vBox = aBottom * lVerticalSide;

написать это:

int boxVolume = bottomArea * verticalHeight;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что правильно, так это убедиться, что все делают одно и то же.

int Box = iBottom * nVerticleSide

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

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

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

Венгерская нотация бессмысленна в типобезопасных языках. например, общий префикс, который вы увидите в старом коде Microsoft, - это "lpsz", что означает "long pointer to a zero-terminated string". С начала 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" - нет никакой веской причины использовать более длинную форму, чем один символ IMHO, поэтому я использую "i" и "p". Меньше печатать, более последовательно, легче читать.

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

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

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

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

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

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

Edit: у Веджа есть статья, которую я имею в виду в своем посте.

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

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

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

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

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