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

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

20 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

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

int vBox = aBottom * lVerticalSide;

но это не так:

int aBottom = lSide1;

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

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

int iLength;
int iVolume;
int iArea;

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

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

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


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

57
30.04.2014 08:07:02
Я рекомендую прочитать blogs.msdn.com/larryosterman/archive/2004/06/22/162629.aspx
Anzurio 7.05.2009 04:18:16
«С современными интеллектуальными редакторами, где вы можете просто навести курсор на любую переменную, чтобы найти полный тип, а не просто сокращение для него, этот тип венгерской нотации потерял много своего значения». Что если вы рассматриваете такие сайты, как pastebin.com, stackoverflow, любую доску с тегами кода или даже веб-браузеры для хранилищ? В этом случае я нахожу эти префиксы такими же полезными, как и в дерьмовом редакторе. На самом деле это главная причина, по которой я до сих пор его использую.
mibollma 14.05.2011 00:38:50
Я все еще думаю, что префикс переменной i для целого числа не имеет смысла, имя переменной должно быть гораздо более выразительным, чем единственный i.
Lasse V. Karlsen 14.05.2011 11:33:51
«Я не использую ни то, ни другое» означает, что вы используете оба.
Ally 13.02.2014 11:48:55

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

thisMethodIsPrettyCool()
this_method_is_pretty_cool()
0
7.08.2008 22:39:04

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

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

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

0
7.08.2008 23:19:32

Это бессмысленно (и отвлекает), но в моей компании оно используется относительно интенсивно, по крайней мере, для таких типов, как int, string, booleans и double.

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

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

9
7.08.2008 22:45:18
что случилось ? и как я начинаю становиться раком?
justjoe 9.08.2010 14:49:36

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

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

int vBox = aBottom * lVerticalSide;

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

int boxVolume = bottomArea * verticalHeight;

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

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

9
7.08.2008 22:52:06

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

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

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

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

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

22
7.08.2008 22:56:03

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

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

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

14
8.08.2008 01:44:58
Я использую firstNameLabel и firstNameTextBox
Mark Cidade 10.09.2008 00:29:07

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

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

1
8.08.2008 06:09:49

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

5
13.08.2008 16:31:27

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

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

int Box = iBottom * nVerticleSide
1
13.08.2008 17:17:25

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

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

1
27.08.2008 13:55:47
Это огромная выгода и при отладке, рассматривайте это как «намерение» ожидаемого хранимого типа.
Daniel Sokolowski 7.04.2016 13:55:16

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

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

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

0
27.08.2008 14:14:29

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

1
23.05.2017 12:17:07

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

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

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

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

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

4
9.09.2008 23:05:05

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

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

0
9.09.2008 23:41:17

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

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

5
17.09.2008 03:24:39

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

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

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

5
20.09.2008 08:44:40

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

2
24.10.2008 13:46:41

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

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

  • м = участник
  • c = const
  • 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), поэтому я всегда знаю, что делает итератор.
  • В циклах вы можете смешивать несколько связанных переменных, используя одно и то же базовое имя с разными префиксами: Orange orange = pOrange [iOrange]; Это также означает, что вы не делаете ошибок индексации массива (pApple [i] выглядит нормально, но пишите его как pApple [iOrange], и ​​ошибка сразу становится очевидной).
  • Многие программисты будут использовать мою систему, не зная об этом: добавляя длинный суффикс, такой как «Index» или «Ptr», - нет веской причины использовать более длинную форму, чем один символ IMHO, поэтому я использую «i» и « п". Меньше печатать, более последовательный, легче читать.

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

1
25.05.2009 15:48:26

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

0
3.09.2009 02:19:25