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

голоса
29

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

Задан 07/08/2008 в 23:31
источник пользователем
На других языках...                            


20 ответов

голоса
56

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

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

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

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

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

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

int vBox = aBottom * lVerticalSide;

но это не делает:

int aBottom = lSide1;

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

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

int iLength;
int iVolume;
int iArea;

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

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

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


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

Ответил 07/08/2008 в 23:39
источник пользователем

голоса
19

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

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

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

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

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

Ответил 07/08/2008 в 23:56
источник пользователем

голоса
13

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

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

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

Ответил 08/08/2008 в 02:44
источник пользователем

голоса
9

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

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

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

Ответил 07/08/2008 в 23:45
источник пользователем

голоса
8

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

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

int vBox = aBottom * lVerticalSide;

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

int boxVolume = bottomArea * verticalHeight;

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

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

Ответил 07/08/2008 в 23:52
источник пользователем

голоса
5

Не сфера важнее ввести в эти дни, например,

  • л для локального
  • а при аргументе
  • м для члена
  • г для глобальной
  • и т.д

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

Ответил 20/09/2008 в 09:44
источник пользователем

голоса
5

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

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

Ответил 17/09/2008 в 04:24
источник пользователем

голоса
5

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

Ответил 13/08/2008 в 17:31
источник пользователем

голоса
4

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

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

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

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

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

Ответил 10/09/2008 в 00:05
источник пользователем

голоса
2

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

Ответил 24/10/2008 в 14:46
источник пользователем

голоса
1

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

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

  • м = член
  • с = Const
  • s = статическое
  • v = летучее
  • р = указатель (и р = указатель на указатель, и т.д.)
  • я = индекс или итератора

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

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

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

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

Ответил 25/05/2009 в 16:48
источник пользователем

голоса
1

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

Ответил 27/08/2008 в 15:21
источник пользователем

голоса
1

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

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

Ответил 27/08/2008 в 14:55
источник пользователем

голоса
1

Что плохого в смешивании стандартов.

Что правильно убедившись, что каждый делает то же самое.

int Box = iBottom * nVerticleSide
Ответил 13/08/2008 в 18:17
источник пользователем

голоса
1

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

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

Ответил 08/08/2008 в 07:09
источник пользователем

голоса
1

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

thisMethodIsPrettyCool()
this_method_is_pretty_cool()
Ответил 07/08/2008 в 23:39
источник пользователем

голоса
0

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

Ответил 03/09/2009 в 03:19
источник пользователем

голоса
0

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

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

Ответил 10/09/2008 в 00:41
источник пользователем

голоса
0

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

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

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

Ответил 27/08/2008 в 15:14
источник пользователем

голоса
0

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

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

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

Ответил 07/08/2008 в 23:43
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more