В чем привлекательность венгерских систем? [закрыто]

18

В каких правилах именования вы следуете? Автор говорит:

Также я предпочитаю кодировать, используя венгерскую нотацию от Чарльза Симони.

Я сталкивался с несколькими программистами, которые все еще предпочитают использовать венгерский язык, в основном из венгерского аромата Petzold / Systems. Подумайте dwLength = strlen(lpszName).

Я прочитал « Создание неправильного кода выглядит неправильно» , и я понимаю обоснование для приложений на венгерском языке, где информация о типе домена включена в имена переменных. Но я не понимаю смысла в привязке типа компилятора к имени.

Почему программисты все еще продолжают использовать этот стиль записи? Это просто инерция? Есть ли преимущества, которые перевешивают снижение читабельности? Люди просто учатся игнорировать декораторы при чтении кода, и если да, то как они продолжают увеличивать ценность?

РЕДАКТИРОВАТЬ: Многие ответы объясняют историю, или почему она больше не актуальна, оба из которых рассматриваются в статье, которую я цитировал.

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

AShelly
источник
5
Венгерские нотации были в моде, когда я начинал в IT, но это была полностью кодирующая среда. Простой текстовый редактор без подсветки синтаксиса, intellisense и кодовых файлов, где по несколько сотен строк со всеми переменными, объявленными в начале. Это просто облегчило жизнь, решая, с чем ты имеешь дело. Однако, с современными инструментами и практиками, необходимость в этом ушла в моем выборе, и это действительно должно быть отправлено в историю
GrumpyMonkey
1
Я использовал это много лет назад и никогда не любил это много. Я совсем не скучаю.
MetalMikester
На мой взгляд, самой большой проблемой было использование префиксов, а не суффиксов - даже в венгерских приложениях «бородавка» обычно содержит меньше семантической информации, чем остальная часть имени
jk.

Ответы:

38

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

  1. Быть совместимым с существующей кодовой базой при выполнении технического обслуживания.
  2. Для контроля, например. "TxtFirstName". Нам часто нужно различать (скажем) значение «firstName» и «firstName» элемента управления. Венгерский предоставляет удобный способ сделать это. Конечно, я мог бы набрать «firstNameTextBox», но «txtFirstName» так же легко понять и содержит меньше символов. Более того, использование венгерского означает, что элементы управления одного типа легко найти, и они часто группируются по имени в IDE.
  3. Когда две переменные имеют одинаковое значение, но различаются по типу. Например, «strValue» для значения, фактически введенного пользователем, и «intValue» для того же значения, когда оно было проанализировано, как в целочисленном виде.

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


Обновить:

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

Kramii Восстановить Монику
источник
Отличный ответ, светлячок отвечает на заданный вопрос.
AShelly
только что заметил креативное редактирование моего iphone ... gsub ('firefly', 'полностью');
AShelly
5
+1 за использование квази-венгерского языка для облегчения группировки элементов управления пользовательского интерфейса в IDE. Это единственное использование, которое все еще имеет смысл для новых проектов, и я просто не мог жить без него. Я часто знаю, что элемент управления - это текстовое поле, но не знаю, называется ли оно «FirstName» или просто «Name».
Коди Грей
2
Я согласен с этим ответом. Что касается использования intValue и strValue, вы также можете видеть его как valueAsInt и valueAsStr, поэтому я не знаю, рассматриваю ли я эту венгерскую нотацию, это больше похоже на то, что int и str являются частью имени переменной.
Мишель Кейзерс
2
2 Я предпочитаю полные суффиксы, потому что префиксы могут быть довольно глупыми (что такое a tssbили a tsddi? Да, они существуют). У аббревиатур также есть проблема единообразия, TextBoxпотому что может быть непоследовательность в том, что это tbили нет txt(лично я видел, как «старший» разработчик использует оба в одном окне). На 3 я опускаю венгерский, когда переменная достигает своего окончательного предполагаемого типа (например, я бы использовал valueи strValueв вашем примере).
Джонатан Дикинсон
6

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

  • Мы также можем заметить, что быстрее найти строку, ссылающуюся на TextBox в вашем коде: набрав «txt» в поле поиска.

Не представляйте себе обратное, где каждый элемент имеет свое имя. Возможно, вам медленнее будет найти, куда вы хотите пойти, верно?

То же самое касается ddl, когда мы хотим сослаться на DropDownList, это проще или нет? :)

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

Использование префикса неприменимо для современных компиляторов языков, таких как C #, но оно может использоваться (читаемым) для людей.

Младший М
источник
Это лучший пример его практической ценности, который я слышал. (Но все еще недостаточно, чтобы заставить меня принять это :)
AShelly
1
Префиксы никогда не были для компиляторов, всегда для людей. Изменились не компиляторы, а интегрированные среды разработки, которые предоставляют информацию о типе и более эффективные способы навигации по коду.
Джереми
Я сделаю то же самое с переменными и (особенно) виджетами - часто давая им короткие префиксы для обозначения их типа. Но не до такой степени, чтобы идти на них "полным венгром".
GrandmasterB
4

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

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

Оба стиля возникли в Microsoft. В наши дни в соглашениях Microsoft об именах категорически говорится: «Не используйте венгерскую нотацию».

Майк Сеймур
источник
4

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


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

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

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

Итак, в заключение, единственное отличие, которое я вижу, это износ клавиатуры.

Каз Дракон
источник
1
как сарказм там :)
JohnL 26.10.10
4

Я фактически начал использовать SH в новом коде, который написал в этом месяце.

Мое назначение включало переписывание некоторого кода Perl в JS, чтобы его можно было перенести на клиентскую часть нашего веб-приложения. В Perl SH обычно не требуется из-за сигил ($ string, @array,% hash).

В JavaScript я обнаружил, что SH неоценим для отслеживания типов структур данных. Например,

var oRowData = aoTableData[iRow];

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

tl; dr: SH может быть прекрасно, если у вас сложный код на слабо типизированном языке. Но если ваша IDE может отслеживать типы, предпочтите это.

Стефан Маевский
источник
2

Мне также любопытно увидеть обоснование. Мы знаем, почему они использовали его в прошлом: отсутствие поддержки IDE для информации о типах. Но сейчас? Проще говоря, я думаю, что это традиция. Код C ++ всегда выглядел так, так что зачем что-то менять? Кроме того, когда вы строите поверх предыдущего кода, который использовал венгерскую нотацию, было бы довольно странно, когда вы вдруг прекратили использовать это ...

Павел Дида
источник
2
Код на С ++ не всегда выглядел так: посмотрите книгу Бьярна Страуструпа.
Дж.Б. Уилкинсон
@JBRWilkinson: Чарльз Симони создал венгерскую нотацию около 1976 года ( c2.com/cgi/wiki?HungarianNotation ). Так что это обозначение на самом деле предшествует C ++. Многие, если не большинство программистов на С ++, используют его со дня 1 (т.е. их кодирования). Я понимаю, что Бьярн Страуструп является заметным исключением, как и Линус Торвальдс, но это не меняет фактов.
Павел Дида
2
Я думаю, что венгерский язык всегда был в первую очередь Microsoft. Я не видел, чтобы он широко использовался в Unix и Unix-подобных средах.
Дэвид Торнли
2

Венгерская нотация «Системы» на самом деле была неким замешательством, неправильным пониманием термина «тип». Разработчики систем воспринимали его буквально как тип компилятора (слово, байт, строка, ...), а не как тип домена приложения (индекс строки, индекс столбца, ...).

Но я полагаю, что каждый разработчик проходит несколько этапов стиля, которые в то время казались отличной идеей (а тип префикса действительно кажется хорошей идеей для новичка), прежде чем попасть в ловушку (изменение типа, создание новых значимых префиксов, и т.д). Таким образом, я предполагаю, что есть инерция: от разработчиков, которые не поправляются и не понимают, почему это плохой выбор, от разработчиков, придерживающихся стандартов кодирования, которые требуют практики, и от людей, использующих <windows.h>. Microsoft слишком дорого обходится, чтобы избавиться от префиксной нотации (которая во многих местах неверна: WPARAM?).

Skizz
источник
1
Даже предполагаемое использование не является оптимальным, поскольку создает частную систему типов, о которой не знает компилятор, и, следовательно, не может проверить тип.
Ларри Коулман
@Larry: Хотя это, безусловно, правда, есть программное обеспечение, которое может анализировать исходный код и проверять его соответствие стандарту. Они могут быть в состоянии обеспечить совпадение префиксов в выражениях.
Skizz
1
Мой идеал при использовании статической типизации состоит в том, чтобы набор типов компиляторов был надмножеством набора типов доменов. Затем компилятор может проверить все, без надстроек.
Ларри Коулман
0

Есть одна вещь, которую людям не хватает с венгерским. Венгерская нотация на самом деле работает БОЛЬШОЙ с автозаполнением.

Скажем, у вас есть переменная, а имя - intHeightOfMonster.

Скажем, вы забыли имя переменной

Это может быть heightOfMonster или MonsterHeight или MeasurementMonsterHeight

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

Зная, что heightOfMonster - это int, вы просто набираете i и вуаля.

Экономьте время

user114310
источник