Почему я не должен использовать “Венгерскую нотацию”?
https://stackoverflow.com/questions/111933
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я знаю, что означает венгерский язык - предоставление информации о переменной, параметре или типе в качестве префикса к ее имени.Кажется, все яростно против этого, хотя в некоторых случаях это кажется хорошей идеей.Если я чувствую, что передается полезная информация, почему я не должен размещать ее прямо там, где она доступна?
Смотрите также: Используют ли люди венгерские соглашения об именовании в реальном мире?
Решение
Большинство людей неправильно используют венгерскую нотацию и получают неправильные результаты.
Прочтите эту замечательную статью Джоэла Спольски: Чтобы Неправильный код Выглядел Неправильно.
Короче говоря, венгерская нотация, в которой вы добавляете к именам ваших переменных их префикс type (string) (Системный венгерский) плох, потому что бесполезен.
Венгерская нотация, как это было задумано ее автором, где вы добавляете к имени переменной ее префикс kind (используя пример Джоэла:безопасная строка (safe string или небезопасная строка), так называемые приложения, которые имеют свое применение и по-прежнему ценны.
Другие советы
Использование adjHungarian nnotation затрудняет чтение ncode adj.
Джоэл ошибается, и вот почему.
Та информация о "приложении", о которой он говорит должно быть закодировано в системе типов.Вы не должны зависеть от изменения имен переменных, чтобы убедиться, что вы не передаете небезопасные данные функциям, требующим безопасных данных.Вы должны сделать это ошибкой типа, чтобы это было невозможно чтобы сделать это.Любые небезопасные данные должны иметь тип, помеченный как небезопасный, чтобы они просто не могли быть переданы безопасной функции.Для преобразования из небезопасного в безопасный должна потребоваться обработка с помощью какой-либо функции очистки.
Многие вещи, о которых Джоэл говорит как о "видах", на самом деле таковыми не являются;на самом деле это разные типы.
Однако чего не хватает большинству языков, так это системы типов, достаточно выразительной, чтобы проводить такого рода различия.Например, если бы C имел своего рода "strong typedef" (где имя typedef содержало все операции базового типа, но не было конвертируемым в него), то многие из этих проблем исчезли бы.Например, если бы вы могли сказать, strong typedef std::string unsafe_string; чтобы ввести новый тип unsafe_string это не могло быть преобразовано в std::string (и поэтому могло участвовать в разрешении перегрузки и т.д.и т.д.), тогда нам не понадобились бы глупые префиксы.
Таким образом, основное утверждение о том, что венгерский язык предназначен для обозначения вещей, которые не являются типами, неверно.Он используется для получения информации о типе.Безусловно, более богатая информация о типе, чем традиционная информация о типе C;это информация о типе, которая кодирует какую-то семантическую деталь, указывающую на назначение объектов.Но это все равно информация о типе, и правильным решением всегда было закодировать ее в систему типов.Кодирование его в систему типов - безусловно, лучший способ получить надлежащую проверку и обеспечение соблюдения правил.Имена переменных просто не имеют значения.
Другими словами, целью не должно быть "сделать так, чтобы неправильный код выглядел неправильным для разработчика".Это должно быть "сделать неправильный код неправильным к компилятору".
Я думаю, что это сильно загромождает исходный код.
Это также не принесет вам большой пользы в строго типизированном языке.Если вы совершите какую-либо глупость с несоответствием типов, компилятор сообщит вам об этом.
Венгерская нотация имеет смысл только в языках без пользовательских типов.На современном функциональном или OO-языке вы бы закодировали информацию о "виде" значения в тип данных или класс, а не в имя переменной.
Ссылка на несколько ответов Статья Джоэлса.Обратите внимание, однако, что его пример находится в VBScript, который не поддерживал пользовательские классы (по крайней мере, долгое время).В языке с пользовательскими типами вы бы решили ту же проблему, создав HtmlEncodedString-тип, а затем позволили методу Write принимать только это.В статически типизированном языке компилятор перехватит любые ошибки кодирования, в динамически типизированном вы получите исключение во время выполнения, но в любом случае вы защищены от записи некодированных строк.Венгерские обозначения просто превращают программиста в человека, проверяющего типы, с такой работой обычно лучше справляется программное обеспечение.
Джоэл проводит различие между "systems hungarian" и "apps hungarian", где "systems hungarian" кодирует встроенные типы, такие как int, float и так далее, а "apps hungarian" кодирует "kinds", что является высокоуровневой метаинформацией о переменной за пределами типа machine, В OO или современном функциональном языке вы можете создавать пользовательские типы, поэтому в этом смысле нет различия между type и "kind" - оба могут быть представлены типом system - и "приложения" на венгерском языке так же избыточны, как и "системы" на венгерском.
Итак, чтобы ответить на ваш вопрос: Системы венгерского языка было бы полезно только в небезопасном, слабо типизированном языке, где, напримерприсвоение переменной int значения с плавающей запятой приведет к аварийному завершению работы системы.Венгерская нотация была специально изобретена в шестидесятых годах для использования в BCPL, довольно низкоуровневый язык, который вообще не выполнял никакой проверки типов.Я не думаю, что какой-либо язык, широко используемый сегодня, имеет эту проблему, но нотация продолжала существовать как своего рода программирование культа груза.
Приложения на венгерском языке будет иметь смысл, если вы работаете с языком без определяемых пользователем типов, таким как устаревший VBScript или ранние версии VB.Возможно, также ранние версии Perl и PHP.Опять же, использование его в современном языке - это чистый культ карго.
На любом другом языке венгерский просто уродлив, избыточен и хрупок.Он повторяет информацию, уже известную из системы типов, и вам не следует повторяться.Используйте описательное имя для переменной, которое описывает назначение данного конкретного экземпляра типа.Используйте систему типов для кодирования инвариантов и метаинформации о "видах" или "классах" переменных - т.е.типы.
Общий смысл статьи Джоэлса - заставить неправильный код выглядеть неправильно - это очень хороший принцип.Однако еще лучшей защитой от ошибок является - когда это вообще возможно - автоматическое обнаружение компилятором неправильного кода.
Я всегда использую венгерскую нотацию для всех своих проектов.Я нахожу это действительно полезным, когда имею дело со сотнями разных имен идентификаторов.
Например, когда я вызываю функцию, требующую строку, я могу ввести 's' и нажать control-space, и моя IDE покажет мне точные имена переменных с префиксом 's' .
Еще одно преимущество, когда я добавляю префикс u для неподписанных и i для подписанных целых чисел, я сразу вижу, где я смешиваю подписанные и неподписанные потенциально опасными способами.
Я не могу вспомнить, сколько раз в огромной кодовой базе из 75000 строк возникали ошибки (мной и другими тоже) из-за того, что локальные переменные именовались так же, как существующие переменные-члены этого класса.С тех пор я всегда ставлю перед участниками префикс "m_".
Это вопрос вкуса и опыта.Не стучите по нему, пока не попробуете.
Вы забываете о причине номер один для включения этой информации.Это не имеет никакого отношения к вам, программисту.Это имеет непосредственное отношение к человеку, который придет на работу через 2-3 года после того, как вы уйдете из компании, и которому придется прочитать этот материал.
Да, IDE быстро определит типы для вас.Однако, когда вы читаете несколько длинных пакетов кода "бизнес-правил", приятно не делать паузу над каждой переменной, чтобы выяснить, к какому типу она относится.Когда я вижу такие вещи, как strUserID, intProduct или guiProductID, это приводит к многое легче "наращивать" время.
Я согласен, что MS зашла слишком далеко в некоторых своих соглашениях об именовании - я отношу это к категории "слишком много хорошего".
Соглашения об именовании - это хорошая вещь, при условии, что вы их придерживаетесь.Я просмотрел достаточно старый код, который заставлял меня постоянно возвращаться к просмотру определений для стольких переменных с одинаковыми именами, что я нажимаю "camel cashing" (как это называлось на предыдущей работе).Прямо сейчас я нахожусь на работе, которая содержит много тысяч строк полностью раскомментированного классического 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.
В старые добрые времена, до того, как для DOS существовало что-либо похожее на IDE (скорее всего, у вас не было достаточно свободной памяти для запуска компилятора под Windows, поэтому ваша разработка велась в DOS), вы не получали никакой помощи от наведения курсора мыши на имя переменной.(Предполагая, что у вас была мышь.) С чем вам приходилось иметь дело, так это с функциями обратного вызова событий, в которых все передавалось вам либо как 16-битный int (WORD), либо как 32-битный int (ДЛИННОЕ СЛОВО).Затем вам нужно было привести эти параметры к соответствующим типам для данного типа события.По сути, большая часть API была практически бестипизированной.
В результате получается API с такими именами параметров, как эти:
LRESULT CALLBACK WindowProc(HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam);
Обратите внимание, что имена wParam и lParam, хотя и довольно ужасные, на самом деле ничуть не хуже, чем называть их param1 и param2.
Что еще хуже, в Windows 3.0 / 3.1 было два типа указателей: ближний и дальний.Так, например, возвращаемое значение из функции управления памятью LocalLock было PVOID, но возвращаемое значение из GlobalLock было LPVOID (с 'L' для long).Затем эта ужасная нотация была расширена, так что lонг pпоследняя строка имела префикс lp, чтобы отличить его от строки, которая просто была malloc'd.
Неудивительно, что против подобных вещей возникла негативная реакция.
Венгерская нотация может быть полезна в языках без проверки типов во время компиляции, поскольку это позволило бы разработчику быстро напомнить себе, как используется конкретная переменная.Это ничего не влияет на производительность или поведение.Предполагается, что это улучшает читаемость кода и в основном зависит от вкуса и стиля кодирования.Именно по этой причине многие разработчики критикуют его - не у всех в мозгу одинаковая проводка.
Для языков проверки типов во время компиляции это в основном бесполезно - прокрутка вверх на несколько строк должна показать объявление и, следовательно, тип.Если у вас глобальные переменные или ваш блок кода занимает гораздо больше одного экрана, у вас возникают серьезные проблемы с дизайном и возможностью повторного использования.Таким образом, одно из критических замечаний заключается в том, что венгерская нотация позволяет разработчикам иметь плохой дизайн и легко выходить сухими из воды.Вероятно, это одна из причин ненависти.
С другой стороны, могут быть случаи, когда даже языки для проверки типов во время компиляции выиграли бы от венгерской нотации -- пустота указатели или РУЧКАэто в 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 по-прежнему является целым числом, но мы рассматриваем его как строку, если нам нужна строка.Если нам нужен поплавок, то мы рассматриваем его как поплавок.В динамически типизированных языках, таких как Python, венгерская нотация бессмысленна, потому что не имеет значения, к какому типу относится что-либо, пока вы это не используете, и если вам нужен определенный тип, то просто убедитесь, что вы привели его к этому типу (например float(foo)) когда вы им пользуетесь.
Обратите внимание, что динамические языки, такие как PHP, не обладают этим преимуществом - PHP пытается делать "правильные вещи" в фоновом режиме на основе неясного набора правил, которые почти никто не запомнил, что часто неожиданно приводит к катастрофическим сбоям.В данном случае, какой-то механизм именования, например $files_count или $file_name, может быть удобно.
На мой взгляд, венгерская нотация подобна пиявкам.Возможно, в прошлом они были полезны, или, по крайней мере, казались полезными, но в настоящее время это просто много дополнительного набора текста, который не приносит большой пользы.
Среда разработки должна предоставлять эту полезную информацию.Венгерский язык, возможно, имел какой-то (не очень большой, но какой-то) смысл, когда IDE были гораздо менее продвинутыми.
Приложения Венгерский для меня - это греческий... в хорошем смысле
Как инженер, а не программист, я сразу же обратил внимание на статью Джоэла о достоинствах приложений.: "Чтобы Неправильный код выглядел неправильно".Мне нравятся приложения на венгерском, потому что это имитирует то, как инженерия, естественные науки и математика представляют уравнения и формулы, используя дополнительные и дополнительные символы (например, греческие буквы, математические операторы и т.д.).Возьмем конкретный пример Закон всемирного тяготения Ньютона:сначала в стандартной математической нотации, а затем в приложениях с венгерским псевдокодом:
frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)
В математической системе счисления наиболее заметными символами являются те, которые представляют добрый информации, хранящейся в переменной:сила, масса, вектор положения и т.д.Нижние индексы играют вторую скрипку для уточнения:положение чего?Это именно то, что делает Apps Hungarian;это говорит вам о добрый сначала о том, что хранится в переменной, а затем переходим к конкретике - о том, насколько код ближе всего подходит к математической нотации.
Очевидно, что строгий ввод текста может решить проблему безопасного ввода текста.небезопасный пример строки из эссе Джоэла, но вы бы не стали определять отдельные типы для векторов положения и скорости;оба представляют собой двойные массивы третьего размера, и все, что вы, вероятно, сделаете с одним, может быть применено к другому.Кроме того, имеет смысл объединить положение и скорость (чтобы создать вектор состояния) или взять их скалярное произведение, но, вероятно, не добавлять их.Как бы набор текста разрешал первые два и запрещал второй, и как бы такая система распространялась на все возможные операции, которые вы, возможно, захотите защитить?Если только вы не захотели закодировать всю математику и физику в своей системе набора текста.
Вдобавок ко всему этому, большая часть инженерных работ выполняется на слабо типизированных языках высокого уровня, таких как Matlab, или на старых, таких как Fortran 77 или Ada.
Так что, если у вас навороченный язык, IDE и приложения, венгерский вам не помогает, забудьте об этом - многие люди, по-видимому, так и сделали.Но для меня, хуже, чем для начинающего программиста, работающего на слабо или динамически типизированных языках, я могу писать лучший код быстрее с приложениями на венгерском, чем без него.
Это невероятно избыточно и бесполезно для большинства современных IDE, где они хорошо справляются с тем, чтобы сделать тип очевидным.
Плюс - для меня - просто раздражает видеть intI, strUserName и т.д.:)
Если я чувствую, что передается полезная информация, почему я не должен размещать ее прямо там, где она доступна?
Тогда кого волнует, что думают другие?Если вы находите это полезным, то используйте обозначение.
По моему опыту, это плохо, потому что:
1 - затем вы нарушаете весь код, если вам нужно изменить тип переменной (т. е.если вам нужно расширить 32-битное целое число до 64-битного целого числа);
2 - это бесполезная информация, поскольку тип либо уже есть в объявлении, либо вы используете динамический язык, где фактический тип не должен быть так важен в первую очередь.
Более того, с языком, принимающим универсальное программирование (т.е.функции, где тип некоторых переменных не определяется при написании функции) или с системой динамической типизации (т.е.когда тип даже не определен во время компиляции), как бы вы назвали свои переменные?И большинство современных языков поддерживают тот или иной вариант, пусть и в ограниченной форме.
В Джоэл Сполски Выставляет Неправильный код В Неправильном свете он объясняет, что то, что все считают венгерской нотацией (которую он называет системной венгерской), на самом деле не является тем, чем оно должно было быть на самом деле (то, что он называет венгерскими приложениями).Прокрутите вниз до Я из Венгрии направляюсь посмотреть это обсуждение.
По сути, системный венгерский язык ничего не стоит.Он просто говорит вам то же самое, что скажет вам ваш компилятор и / или IDE.
Apps Hungarian сообщает вам, что должна означать переменная, и действительно может быть полезна.
Я всегда думал, что пара префиксов в нужном месте не повредят.Я думаю, если я могу поделиться чем-то полезным, например, "Эй, это интерфейс, не рассчитывайте на конкретное поведение" прямо здесь, как в IEnumerable, я должен это сделать.Комментарий может загромождать все гораздо больше, чем просто одно- или двухсимвольный символ.
Это полезное соглашение для присвоения имен элементам управления в форме (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, "найти во всех файлах"), чтобы найти КАЖДОЕ упоминание об этой "идее".
Почему это важно, когда у нас есть IDE, которые знают, как читать код?Потому что они пока не очень хороши в этом.Это трудно увидеть в небольшой кодовой базе, но очевидно в большой - когда "идея" может быть упомянута в комментариях, Файлы XML, Perl скрипты, а также в местах, находящихся вне контроля источника (документы, Вики-сайты база данных ошибок).
Вы должны быть немного осторожны даже здесь - напримервставка токена в макросы C / C ++ может скрывать упоминания идентификатора.С такими случаями можно справиться, используя соглашения о кодировании, и в любом случае они, как правило, затрагивают лишь меньшинство идентификаторов в кодовой базе.
P.S.К вопросу об использовании системы типов по сравнениюВенгерский - лучше всего использовать оба варианта.Вам нужен неправильный код только для того, чтобы выглядеть неправильно, если компилятор не поймает его за вас.Есть много случаев, когда невозможно заставить компилятор перехватить это.Но там, где это возможно - да, пожалуйста, сделайте это вместо этого!
Однако, рассматривая целесообразность, учитывайте негативные последствия разделения типов.например ,в C # обертывание 'int' не встроенным типом имеет огромные последствия.Так что это имеет смысл в некоторых ситуациях, но не во всех.
Разоблачение преимуществ венгерской нотации
- Это обеспечивает способ различения переменных.
Если тип - это все, что отличает одно значение от другого, то это может быть только для преобразования одного типа в другой.Если у вас есть одно и то же значение, которое преобразуется между типами, скорее всего, вы должны делать это в функции, предназначенной для преобразования. (Я видел венгерские остатки VB6, использующие строки для всех параметров своего метода просто потому, что они не могли понять, как десериализовать объект JSON, или правильно понять, как объявлять или использовать типы с нулевым значением.) Если у вас есть две переменные, отличающиеся только венгерским префиксом, и они не являются преобразованием из одной в другую, то вам нужно уточнить ваше намерение относительно них.
- Это делает код более читабельным.
Я обнаружил, что венгерская нотация делает людей ленивыми с именами переменных.У них есть что-то, что отличает его, и они не чувствуют необходимости вдаваться в подробности относительно его назначения.Это то, что вы обычно найдете в коде с венгерской нотацией .современный:sSQL противgroupSelectSql (или, как правило, вообще нет sSQL, потому что предполагается, что они используют ORM, который был введен более ранними разработчиками.), значение противFormcollectionзначение (или обычно никакого значения тоже нет, потому что они находятся в MVC и должны использовать его функции привязки к модели), Стип противpublishSource и т.д.
Это не может быть удобочитаемостью.Я вижу больше sTemp1, sTemp2...сТемпН от любого данного венгерского VB6, оставшегося от всех остальных, вместе взятых.
- Это предотвращает ошибки.
Это было бы в силу числа 2, которое является ложным.
По словам мастера:
http://www.joelonsoftware.com/articles/Wrong.html
Интересное чтение, как обычно.
Выдержки:
"Кто-то где-то прочитал статью Симони, где он использовал слово “тип”, и подумал, что он имеет в виду тип, как класс, как в системе типов, как проверка типов, которую выполняет компилятор.Он этого не сделал.Он очень тщательно объяснил, что именно он имел в виду под словом “тип”, но это не помогло.Ущерб был нанесен ".
"Но приложения на венгерском языке по-прежнему имеют огромную ценность, поскольку увеличивают количество словосочетаний в коде, что облегчает чтение, запись, отладку и сопровождение кода, и, что наиболее важно, из-за этого неправильный код выглядит неправильно".
Убедитесь, что у вас есть немного времени, прежде чем читать Джоэла о программном обеспечении.:)
Несколько причин:
- Любая современная среда разработки IDE предоставит вам тип переменной, просто наведя курсор мыши на нее.
- Большинство имен типов очень длинные (подумайте HttpClientRequestProvider) разумно использовать в качестве префикса.
- Информация о типе не содержит правильно информация, это просто перефразирование объявления переменной, вместо того чтобы описывать цель переменной (подумайте Мой интегратор против. Размер страницы).
Я не думаю, что все яростно против этого.В языках без статических типов это довольно полезно.Я определенно предпочитаю, когда он используется для предоставления информации, которой еще нет в типе.Как в C, символ * 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 world, поэтому используем похожий стиль кода (выровненные фигурные скобки, мне это нравится!, заглавные буквы в именах методов, я к этому привык, префикс типа m_ для членов класса (полей), s_ для статических членов и т.д.).
И они сказали, что все переменные должны иметь префикс, показывающий их тип (например.BufferedReader называется brData).Что показано как плохая идея, поскольку типы могут меняться, но имена не следуют, или программисты непоследовательны в использовании этих префиксов (я даже вижу aBuffer, theProxy и т.д.!).
Лично я выбрал несколько префиксов, которые нахожу полезными, наиболее важным из которых является b для префикса логических переменных, поскольку они единственные, где я допускаю такой синтаксис, как if (bVar) (не используется автоматическое преобразование некоторых значений в true или false).Когда я кодировал на C, я использовал префикс для переменных, выделенных с помощью malloc, в качестве напоминания, что его следует освободить позже.И т.д.
Итак, в принципе, я не отвергаю эту нотацию в целом, но взял то, что кажется подходящим для моих нужд.
И, конечно, внося свой вклад в какой-либо проект (рабочий, с открытым исходным кодом), я просто использую существующие соглашения!
