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

Question

Стоит ли изучать это соглашение или это вредно для читаемости и удобства обслуживания?

Answer 1

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

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

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

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

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

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

int vBox = aBottom * lVerticalSide;

но это не так:

int aBottom = lSide1;

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

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

int iLength;
int iVolume;
int iArea;

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

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

Но вам следует принять собственное решение.Могу сказать только одно: я тоже не пользуюсь.

---

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

Answer 2

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

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

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

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

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

Answer 3

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

lblFirstName для объекта метки, txtFirstName для текстового поля.Я определенно не могу назвать их обоих «Имя», даже если что является заботой/ответственностью обоих объектов.

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

Answer 4

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

Вещи как sValue, iCount, dAmount или fAmount, и bFlag есть повсюду.

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

Answer 5

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

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

int vBox = aBottom * lVerticalSide;

напиши это:

int boxVolume = bottomArea * verticalHeight;

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

• я за местный
• а для аргумента
• м для члена
• г для глобального
• и т. д.

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

Answer 9

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

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

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

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

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

Answer 10

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

Answer 11

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

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

Answer 12

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

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

int Box = iBottom * nVerticleSide

Answer 13

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

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

Answer 14

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

Answer 15

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

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

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

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

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

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

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

Answer 16

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

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

Answer 17

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

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

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

Answer 18

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

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

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

Answer 19

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

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

Answer 20

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