Я знаю, к чему относится венгерский - предоставление информации о переменной, параметре или типе в качестве префикса для его имени. Кажется, все бешеные против нее, хотя в некоторых случаях это кажется хорошей идеей. Если я чувствую, что полезная информация передается, почему я не должен ее размещать там, где она доступна?
См. также: Используют ли люди венгерские соглашения об именах в реальном мире?
Большинство людей используют венгерскую нотацию неправильно и получают неправильные результаты.
Прочитайте эту замечательную статью Джоэла Спольского: Неверный код неправильного кода.
Короче говоря, венгерская нотация, в которой вы префикс своих имен переменных с их type (string) (Systems Hungarian) плоха, потому что это бесполезно.
Венгерская нотация, как она была задумана ее автором, где вы префиксное имя переменной своим kind (с использованием примера Джоэл: безопасная строка или небезопасная строка), так называемые приложения Hungarian имеют свои применения и по-прежнему ценны.
vUsing adjHungarian nnotation vmakes nreading ncode adjdifficult.
Джоэл ошибается, и вот почему.
Эта информация о "приложении", о которой он говорит, должна быть закодирована в системе типов. Вы не должны зависеть от перелистывания имен переменных, чтобы убедиться, что вы не передаете небезопасные данные в функции, требующие безопасных данных. Вы должны сделать ошибку типа, так что это невозможно сделать. Любые небезопасные данные должны иметь тип, который помечен как небезопасный, так что он просто не может быть передан в безопасную функцию. Чтобы преобразовать из небезопасного в безопасное, требуется обработка с помощью какой-либо функции санитизации.
Многие вещи, которые Джоэл говорит как "виды", не являются видами; они действительно являются типами.
Однако большинство языков не является системой типов, которая достаточно выразительна, чтобы обеспечить соблюдение этих различий. Например, если C имеет своего рода "сильный typedef" (где имя typedef имеет все операции базового типа, но не конвертируется в него), тогда многие из этих проблем исчезнут. Например, если вы могли бы сказать, strong typedef std::string unsafe_string; ввести новый тип unsafe_string, который не может быть преобразован в std::string (и поэтому может участвовать в разрешении перегрузки и т.д.), Тогда нам не нужны глупые префиксы.
Итак, центральное утверждение о том, что венгерский относится к вещам, которые не относятся к типам, неверно. Он используется для информации типа. Более богатая информация о типе, чем традиционная информация типа С, конечно; он печатает информацию, которая кодирует некоторую семантическую деталь, чтобы указать цель объектов. Но он по-прежнему печатает информацию, и правильное решение всегда заключалось в ее кодировании в систему типов. Кодирование его в систему типов - это лучший способ получить правильную проверку и применение правил. Имена переменных просто не разрезают горчицу.
Другими словами, цель не должна заключаться в том, чтобы "сделать неправильный код неправильным для разработчика". Это должно быть "сделать неправильный код неправильным для компилятора".
Я думаю, что он массово загромождает исходный код.
Он также не сильно вас набирает на строго типизированном языке. Если вы делаете какой-либо тип несовместимости tomfoolery, компилятор расскажет вам об этом.
Венгерская нотация имеет смысл только в языках без пользовательских типов. В современном функциональном или OO-языке вы должны кодировать информацию о "вид" значения в тип данных или класс, а не в имя переменной.
Несколько ответов ссылаются на статью Джоэлса. Однако обратите внимание, что его пример находится в VBScript, который не поддерживает определяемые пользователем классы (как минимум, в течение длительного времени). На языке с пользовательскими типами вы решили бы ту же проблему, создав тип HtmlEncodedString, а затем пусть метод Write примет только это. В статически типизированном языке компилятор поймает любые ошибки кодирования, в динамически типизированном вы получите исключение во время выполнения, но в любом случае вы защищены от записи некодированных строк. Венгерские нотации просто превращают программиста в человеческий метод проверки типов, с той работой, которая обычно лучше обрабатывается программным обеспечением.
Джоэл различает "венгерские системы" и "приложения венгерский", где "системы венгерские" кодируют встроенные типы, такие как int, float и т.д., а "приложения венгерские" кодируют "виды", которые являются более высокоуровневыми meta-info о переменной beane тип машины. В OO или современном функциональном языке вы можете создавать пользовательские типы, поэтому нет различия между типом и "видом" в этом смысле - оба могут быть представлены системой типов - и "Приложения" венгерские так же излишни, как "системы" венгерские.
Итак, чтобы ответить на ваш вопрос: системы, венгерские, были бы полезны только на небезопасном, слабо типизированном языке, например, присвоение значения float переменной int приведет к сбою системы. Венгерская нотация была специально изобретена в шестидесятых годах для использования в BCPL, довольно низкоуровневом языке, который вообще не выполнял проверку типов, Я не думаю, что любой язык в общем использовании сегодня имеет эту проблему, но нотация была в виде своего рода культового программирования груза.
Приложения, венгерские, будут иметь смысл, если вы работаете с языком без определенных пользователем типов, например, старым VBScript или ранними версиями VB. Возможно, также ранние версии Perl и PHP. Опять же, использование его в современном языке - это курьерский груз.
На любом другом языке венгерский просто уродливый, избыточный и хрупкий. Он повторяет информацию, уже известную из системы типов, и вам не следует повторять. Используйте описательное имя для переменной, которая описывает намерение этого конкретного экземпляра типа. Используйте систему типов для кодирования инвариантов и метаинформации о "видах" или "классах" переменных - т.е. типы.
Общий смысл статьи Джоэлса - неправильный код выглядит неправильно - это очень хороший принцип. Однако даже более эффективная защита от ошибок заключается в том, чтобы, когда это вообще возможно, неправильно компилировать код, который будет автоматически обнаружен компилятором.
Я всегда использую венгерскую нотацию для всех моих проектов. Я считаю, что это действительно полезно, когда я имею дело с 100 именами разных идентификаторов.
Например, когда я вызываю функцию, требующую строку, я могу напечатать 's' и hit control-space, и моя IDE покажет мне точно имена переменных, префикс которых 's'.
Еще одно преимущество, когда я префикс u для unsigned и я для подписанных ints, я сразу вижу, где я смешиваю подписанные и unsigned потенциально опасные способы.
Я не могу вспомнить количество раз, когда в огромной кодовой базе 75000 строк были вызваны ошибки (и мной и другими) из-за того, что имена локальных переменных совпадали с существующими переменными-членами этого класса. С тех пор я всегда приписываю членам 'm _'
Это вопрос вкуса и опыта. Не стучите, пока не попробуете.
Вы забываете причину номер один, чтобы включить эту информацию. Это не имеет никакого отношения к вам, программист. Это имеет отношение к человеку, спускающемуся через дорогу через 2 или 3 года после того, как вы покинете компанию, которая должна прочитать это.
Да, среда IDE быстро идентифицирует вас. Однако, когда вы просматриваете некоторые длинные партии кода "бизнес-правил", приятно не останавливаться на каждой переменной, чтобы узнать, какой тип она есть. Когда я вижу такие вещи, как strUserID, intProduct или guiProductID, он значительно упрощает "увеличение времени".
Я согласен с тем, что MS слишком далеко продвинулась с некоторыми из своих соглашений об именах - я категоризую это в кучке "слишком много хорошего".
Соглашения об именах - это хорошие вещи, если вы придерживаетесь их. Я прошел достаточно старый код, который заставил меня постоянно возвращаться к определениям для стольких именных переменных, которые я нажимаю на "верблюжьей оболочке" (как это называлось на предыдущем задании). Прямо сейчас я нахожусь на работе, у которой есть много тысяч строк совершенно безкомментированного классического ASP-кода с VBScript, и это кошмар, пытающийся понять, что происходит.
Устранение загадочных символов в начале каждого имени переменной необязательно и показывает, что имя переменной само по себе недостаточно описательно. Для большинства языков в любом случае требуется тип переменной при объявлении, так что информация уже доступна.
Также существует ситуация, когда во время обслуживания изменяется тип переменной. Пример: если переменная, объявленная как "uint_16 u16foo", должна стать 64-разрядной беззнаковой, произойдет одна из двух:
Джоэл Спольский написал хорошее сообщение в блоге об этом. http://www.joelonsoftware.com/articles/Wrong.html В основном это сводится к тому, что ваш код не будет более читаемым, когда достойная среда IDE скажет, что вы хотите ввести переменную, если вы не можете ее запомнить. Кроме того, если вы достаточно изолируете свой код, вам не нужно запоминать, какая переменная была объявлена как три страницы.
В настоящее время область не важна, чем тип, например
* l for local
* a for argument
* m for member
* g for global
* etc
С современными методами рефакторинга старого кода поиск и замена символа, потому что вы изменили его тип, утомительно, компилятор будет улавливать изменения типа, но часто не будет ловить неправильное использование области, разумные соглашения об именах помогут здесь.
Нет причин, по которым вы не должны правильно использовать венгерскую нотацию. Это непопулярность объясняется долговременной обратной заторможенностью от неправильного использования венгерской нотации, особенно в Windows API.
В плохие старые дни, прежде чем что-либо похожее на IDE существовало для DOS (вероятность того, что у вас недостаточно свободной памяти для запуска компилятора под Windows, поэтому ваша разработка была выполнена в DOS), вы не получили любая помощь от наведения указателя мыши на имя переменной. (Предполагая, что у вас есть мышь.) Что вы имели в виду - это функции обратного вызова событий, в которых все было передано вам как 16-битное int (WORD) или 32-битное int (LONG WORD). Затем вам нужно было применить этот параметр к соответствующим типам для данного типа события. Фактически, большая часть API была практически без текста.
В результате API с именами параметров, такими как:
LRESULT CALLBACK WindowProc(HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam);
Обратите внимание, что имена wParam и lParam, хотя и довольно ужасные, на самом деле не хуже, чем называть их param1 и param2.
Чтобы ухудшить ситуацию, в Window 3.0/3.1 было два типа указателей, близких и далеких. Так, например, возвращаемое значение из функции управления памятью LocalLock было PVOID, но возвращаемое значение из GlobalLock было LPVOID (с длительностью "L" ). Затем эта ужасная нотация расширилась, так что строка l ong p была префикса lp, чтобы отличить ее от строки, которая просто была malloc "д.
Неудивительно, что была реакция на подобные вещи.
Венгерская нотация может быть полезна в языках без проверки типа компиляции, поскольку это позволит разработчику быстро напомнить себе, как используется конкретная переменная. Он ничего не делает для производительности или поведения. Предполагается улучшить читаемость кода и, в основном, это стиль вкуса и кодирования. По этой причине его критикуют многие разработчики - не у всех одинаковая проводка в мозгу.
Для языков проверки типов времени компиляции это в основном бесполезно - прокрутка нескольких строк должна показывать декларацию и, таким образом, вводить ее. Если глобальные переменные или ваш блок кода охватывают более одного экрана, у вас есть серьезные проблемы с дизайном и повторным использованием. Таким образом, одна из критических замечаний заключается в том, что венгерская нотация позволяет разработчикам иметь плохой дизайн и легко уйти от него. Вероятно, это одна из причин ненадежности.
С другой стороны, могут быть случаи, когда даже языковые языки, использующие язык компиляции, выиграют от венгерской нотации - указатели void или HANDLE в win32 API. Они затуманивают фактический тип данных, и может быть заслуга использования Венгерской нотации там. Тем не менее, если вы знаете тип данных во время сборки, почему бы не использовать соответствующий тип данных.
В общем, нет никаких трудных причин не использовать венгерскую нотацию. Это вопрос нравов, политик и стиля кодирования.
Как программист на Python, венгерская нотация довольно быстро разваливается. В Python мне все равно, если что-то является строкой - мне все равно, может ли она действовать как строка (т.е. Если у нее есть метод ___str___(), который возвращает строку).
Например, допустим, что мы имеем foo как целое число, 12
foo = 12
Венгерская нотация говорит нам, что мы должны назвать это iFoo или что-то еще, чтобы обозначить это целое число, так что позже мы знаем, что это такое. За исключением Python, это не работает, точнее, это не имеет смысла. В Python я решаю, какой тип я хочу, когда я его использую. Мне нужна строка? хорошо, если я сделаю что-то вроде этого:
print "The current value of foo is %s" % foo
Обратите внимание на строку %s -. Foo не является строкой, но оператор % вызывает foo.___str___() и использует результат (если он существует). foo по-прежнему является целым числом, но мы рассматриваем его как строку, если хотим строку. Если мы хотим float, то мы рассматриваем его как float. В динамически типизированных языках, таких как Python, венгерская нотация бессмысленна, потому что не имеет значения, какой тип есть до тех пор, пока вы ее не используете, и если вам нужен определенный тип, просто убедитесь, что вы выбрали его для этого типа (например, float(foo)), когда вы его используете.
Обратите внимание, что динамические языки, такие как PHP, не имеют такого преимущества - PHP пытается сделать "правильную вещь" в фоновом режиме на основе неясного набора правил, который почти никто не запомнил, что часто приводит к катастрофическим беспорядкам неожиданно. В этом случае может быть удобен какой-то механизм именования, например $files_count или $file_name.
На мой взгляд, венгерская нотация похожа на пиявки. Возможно, в прошлом они были полезны, или, по крайней мере, они казались полезными, но в настоящее время это просто много лишнего набора текста, не приносящего большой пользы.
IDE должна сообщить эту полезную информацию. Венгерский, возможно, сделал какой-то (не много, но какой-то) смысл, когда IDE были намного менее продвинуты.
Будучи инженером, а не программистом, я сразу же взял статью Джоэля по достоинствам приложений "Венгерский": "Нарушение неправильного кода" . Мне нравится Apps Hungarian, потому что имитирует, как инженерные науки и математика представляют уравнения и формулы, используя символы sub и super-scripted (например, греческие буквы, математические операторы и т.д.). Возьмем конкретный пример Newton Law of Universal Gravity: сначала в стандартной математической нотации, а затем в приложении Венгерский псевдокод:
frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)
В математических обозначениях наиболее заметными символами являются те, которые представляют собой информацию, хранящуюся в переменной: силу, массу, вектор положения и т.д. Нижние индексы играют вторую скрипку, чтобы уточнить: положение чего? Это именно то, что делает Apps Hungarian; он говорит вам, что вещь, хранящаяся в переменной сначала, а затем попадающая в специфику - о ближайшем коде может перейти к математической нотации.
Очевидно, что сильная типизация может разрешить безопасный и небезопасный пример строки из эссе Joel, но вы не определяете отдельные типы векторов положения и скорости; оба являются двойными массивами размера три, и все, что вы, вероятно, сделаете, может быть применимо к другому. Кроме того, имеет смысл объединить положение и скорость (сделать вектор состояния) или взять их точечный продукт, но, вероятно, не добавлять их. Как печатать, разрешить первые два и запретить второе, и как такая система будет распространяться на все возможные операции, которые вы, возможно, захотите защитить? Если вы не хотите кодировать всю математику и физику в своей системе набора текста.
Кроме всего прочего, многие разработки выполняются на слабо типизированных языках высокого уровня, таких как Matlab, или на старых, таких как Fortran 77 или Ada.
Итак, если у вас есть причудливый язык, а IDE и Apps Hungarian не помогут вам, тогда забудьте об этом - похоже, у многих людей есть. Но для меня, хуже, чем начинающий программист, который работает на языках с низким или динамически типизированным языком, я могу быстрее писать код быстрее с помощью Apps Hungarian, чем без него.
Я всегда думал, что префикс или два в нужном месте не повредит. Я думаю, что если я могу передать что-то полезное, например "Эй, это интерфейс, не рассчитывайте на конкретное поведение" прямо, как в IEnumerable, я должен это сделать. Комментарий может загромождать вещи намного больше, чем один или два символа символа.
Это невероятно избыточно и бесполезно, это самые современные IDE, где они хорошо выполняют вид типа.
Плюс - мне - это просто раздражает видеть intI, strUserName и т.д.:)
Если я чувствую, что полезная информация передается, почему я не должен размещать ее там, где она доступна?
Тогда кто заботится о том, что думает кто-то еще? Если вы сочтете это полезным, используйте обозначения.
Мне кажется, это плохо, потому что:
1 - тогда вы разрываете весь код, если вам нужно изменить тип переменной (т.е. если вам нужно расширить 32-битное целое число до 64-битного целого);
2 - это бесполезная информация, поскольку тип либо уже находится в объявлении, либо вы используете динамический язык, где фактический тип не должен быть таким важным в первую очередь.
Кроме того, с языком, принимающим общее программирование (т.е. функции, где тип некоторых переменных не определяется при написании функции) или с системой динамического набора (т.е. когда тип не определяется даже во время компиляции), как вы называете переменные? И большинство современных языков поддерживают тот или иной, даже если в ограниченной форме.
В Джоэл Спольский делает неправильный код выглядят неправильно, он объясняет, что то, что все думают как венгерское обозначение (которое он называет системами венгерский), не что это было на самом деле предназначено (то, что он называет Apps Hungarian). Прокрутите вниз до заголовка Im Hungary, чтобы увидеть это обсуждение.
В принципе, венгерские системы бесполезны. Он просто сообщает вам то же самое, что и ваш компилятор и/или IDE расскажет вам.
Приложения Венгерский говорит вам, что означает переменная, и может быть действительно полезной.
Это полезное соглашение для управления именами в форме (btnOK, txtLastName и т.д.), если список элементов управления отображается в раскрывающемся списке с алфавитом в вашей среде IDE.
Я обычно использую венгерскую нотацию с элементами управления ASP.NET только, в противном случае мне сложно определить, какие элементы управления есть в форме.
Возьмите этот фрагмент кода:
<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />
Если кто-то может показать лучший способ иметь этот набор контрольных имен без венгерского языка, я бы попытался перейти к нему.
Статья Джоэля замечательная, но она, кажется, опускает один важный момент:
Венгерский язык делает особую "идею" (имя вида + идентификатора) уникальной, или почти уникальный, через кодовую базу - даже очень большую базу кода.
Это огромное для обслуживания кода. Это означает, что вы можете использовать хороший текстовый поиск (grep, findstr, "найти во всех файлах" ), чтобы найти КАЖДОЕ упоминание этой "идеи".
Почему это важно, когда у нас есть среда разработки, которая умеет читать код? Потому что они пока не очень хороши. Это трудно увидеть в небольшой базе кода, но очевидно в большом - когда "идея" может быть упомянута в комментариях, XML файлы, скрипты Perl, а также в местах вне контроля источника (документы, вики, базы данных ошибок).
Вам нужно быть немного осторожным даже здесь - например. token-вставка в макросах C/С++ может скрывать упоминания идентификатора. В таких случаях можно кодирования, и в любом случае они имеют тенденцию влиять только на меньшинство идентификаторов в кодовая.
P.S. К вопросу об использовании системы типов против венгерского - лучше всего использовать оба. Вам нужен только неправильный код, чтобы выглядеть неправильно, если компилятор не поймает его для вас. Есть много случаев, когда невозможно сделать компилятор улавливать его. Но где это возможно - да, пожалуйста, сделайте это вместо этого!
При рассмотрении вопроса о целесообразности, однако, рассмотрите отрицательные эффекты разделения типов. например в С# обертка 'int' с нестрогим типом имеет огромные последствия. Поэтому это имеет смысл в некоторых ситуациях, но не во всех из них.
Если тип - это все, что отличает одно значение от другого, то это может быть только для преобразования одного типа в другой. Если у вас есть то же значение, которое преобразуется между типами, скорее всего, вы должны делать это в функции, предназначенной для преобразования. (Я видел, что венгерские остатки VB6 используют строки во всех своих параметрах метода просто потому, что они не могут понять, как десериализовать объект JSON, или правильно понимать, как объявлять или использовать типы с нулевым значением.) Если у вас есть две переменные, отличающиеся только Венгерский префикс, и они не являются переходом от одного к другому, тогда вам нужно уточнить свое намерение с ними.
Я обнаружил, что венгерская нотация делает людей ленивыми с их переменными именами. У них есть что-то, чтобы отличить их, и они не нуждаются в подробностях в своих целях. Это то, что вы обычно найдете в венгерском нотном коде против современного: sSQL vs. groupSelectSql (или вообще не sSQL вообще, потому что они должны использовать ORM, который был добавлен более ранними разработчиками.), SValue и formCollectionValue ( или обычно нет sValue, потому что они попадают в MVC и должны использовать свои возможности привязки к модели), sType vs. publishSource и т.д.
Он не может быть удобочитаемым. Я вижу больше sTemp1, sTemp2... sTempN из любого данного венгерского VB6, оставшегося, кроме всех остальных.
Это будет в силу числа 2, которое является ложным.
В словах мастера:
http://www.joelonsoftware.com/articles/Wrong.html
Интересное чтение, как обычно.
Экстракты:
"Кто-то где-то читал статью Симониса, где он использовал слово" тип ", и думал, что он имеет в виду тип, например класс, как в системе типов, например, тип проверки, который делает компилятор. очень точно объяснил, что он имел в виду под словом" тип ", но это не помогло. Ущерб был нанесен".
"Но theres все еще огромная ценность для Apps Hungarian, поскольку он увеличивает коллокацию в коде, что делает код более легким для чтения, записи, отладки и поддержки, и, что самое главное, он делает неправильный код неправильным."
Убедитесь, что у вас есть время перед чтением Joel On Software.:)
Несколько причин:
Я не думаю, что все в бешенстве против него. В языках без статических типов это довольно полезно. Я определенно предпочитаю его, когда он использовал информацию, которая еще не в типе. Как и в C, char * szName говорит, что переменная будет ссылаться на строку с нулевым завершением - которая не подразумевается в char * - конечно же, typedef также поможет.
У Джоэля была отличная статья о том, как использовать венгерский язык, чтобы определить, была ли переменная закодирована в HTML или нет:
http://www.joelonsoftware.com/articles/Wrong.html
В любом случае, я склонен не любить венгерский язык, когда он использовал информацию, которую я уже знаю.
Конечно, когда 99% программистов согласны с чем-то, что-то не так. Причина, по которой они здесь согласны, состоит в том, что большинство из них никогда не использовали венгерскую нотацию правильно.
Для подробного аргумента я отсылаю вас к сообщению в блоге, которое я сделал по этому вопросу.
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html
Я начал кодировать почти то же самое время, когда была изобретена венгерская нотация, и в первый раз я был вынужден использовать ее в проекте, который я ненавидел.
Через некоторое время я понял, что когда это было сделано правильно, это действительно помогло, и в наши дни мне это нравится.
Но, как и все хорошее, его нужно изучать и понимать, и для этого нужно время.
Венгерская нотация подвергалась насилию, особенно Microsoft, что приводило к префиксам дольше, чем имя переменной, и показывает, что она довольно жесткая, особенно когда вы меняете типы (печально известные lparam/wparam разных типов и размеров в Win16, идентичен в Win32).
Таким образом, как из-за этого злоупотребления, так и из-за его использования с помощью M $, оно было подавлено как бесполезное.
В моей работе мы программируем на Java, но создаем cames из мира MFC, поэтому используйте аналогичный стиль кода (выравниваемые фигурные скобки, мне это нравится!, capitals к именам методов, я привык к этому, префикс как m_ to class члены (поля), s_ для статических членов и т.д.).
И они сказали, что все переменные должны иметь префикс, показывающий его тип (например, BufferedReader называется brData). Что показалось плохой идеей, поскольку типы могут меняться, но имена не следуют, или кодеры несовместимы в использовании этих префиксов (я даже вижу aBuffer, theProxy и т.д.!).
Лично я выбрал несколько префиксов, которые я нахожу полезными, наиболее важным из которых является b для префикса булевых переменных, поскольку они являются единственными, где я допускаю синтаксис как if (bVar) (без использования autocast от некоторых значений до true или false).
Когда я закодирован в C, я использовал префикс для переменных, назначенных malloc, в качестве напоминания, который должен быть освобожден позже. Etc.
Итак, в основном, я не отвергаю эту нотацию в целом, но взял то, что кажется подходящим для моих нужд.
И, конечно, когда я участвую в каком-то проекте (работа, с открытым исходным кодом), я просто использую соглашения на месте!