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

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

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

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

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

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

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

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

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

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

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

Обновить:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

var oRowData = aoTableData[iRow];

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

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

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

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

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

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

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

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

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

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

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

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