Прежде чем использовать С#, С++ был моим основным языком программирования. И венгерская нотация глубоко в моем сердце.
Я сделал несколько небольших проектов на С# без чтения книги С# или других рекомендаций на этом языке. В тех небольших проектах С# я использовал что-то вроде
private string m_strExePath;
Пока я не прочитал что-нибудь из SO, в котором говорилось:
Не используйте венгерскую нотацию.
Так почему? Я единственный человек, который имеет m_strExePath или m_iNumber в моем коде С#?
Джоэл Спольский очень хороший article на эту тему. Краткое изложение состоит в том, что существуют два типа венгерской нотации, которые используются на практике.
Первым является "Systems Hungarian", где вы указываете тип переменной с использованием префикса. Такие вещи, как "str" для строки. Это почти бесполезная информация, тем более, что современные IDE скажут вам тип в любом случае.
Второй вариант - "Приложения венгерский", где вы указываете назначение переменной с префиксом. Наиболее распространенным примером этого является использование "m_" для указания переменных-членов. Это может быть чрезвычайно полезно при правильном выполнении.
Моя рекомендация состояла бы в том, чтобы избежать "систем венгерских", таких как чума, но определенно использовать "Apps Hungarian", где это имеет смысл. Предлагаю прочитать статью Джоэля. Это немного затянуло, но объясняет это намного лучше, чем я мог.
Самая интересная часть этой статьи заключается в том, что оригинальный изобретатель венгерской нотации Чарльз Симони создал "Apps Hungarian", но его статья была ужасно неверно истолкована, и в результате была создана мерзость "Systems Hungarian".
Ты не единственный человек, но я бы сказал, что это довольно редко. Лично я не поклонник венгерской нотации, по крайней мере, не в простом смысле, который просто повторяет информацию типа, которая уже присутствует в декларации. (Поклонники "истинной" венгерской нотации объяснят эту разницу - меня это никогда не беспокоило, но я могу видеть их точку. Если вы используете общий префикс, например, единиц длины по отношению к единицам веса, вы не будете случайно присвойте переменной длины значение веса, хотя оба могут быть целыми числами.)
Тем не менее, для частных членов вы можете в значительной степени делать то, что хотите, - согласитесь с вашей командой, как должно быть соглашение об именах. Важно то, что если вы хотите, чтобы ваш API соответствовал остальной части .NET, не используйте венгерскую нотацию в своих публичных членах (включая параметры).
При разработке пользовательского интерфейса я счел очень полезным поддерживать венгерскую нотацию. Элементы, такие как текстовые поля, ярлыки и выпадающие списки, намного легче понять, и часто вы получаете повторяющиеся имена элементов управления:
lblTitle = Label
txtTitle = TextBox
ddlTitle = DropDownList
Мне это легче читать и разбирать. В противном случае венгерская нотация не вписывается из-за успехов в среде IDE, в частности с Visual Studio.
Кроме того, у Joel on Software есть отличная статья, связанная с венгерской нотацией под названием: Создание неправильного кода Look Wrong, который дает несколько хороших аргументов для венгерской нотации.
Нет, ты не единственный, кто это делает. Как правило, принято считать, что венгерская нотация - это не лучший способ назвать вещи на С# (IDE обрабатывает много проблем, которые пытались адресовать венгерская нотация).
Венгерская нотация - ужасная ошибка на любом языке. Вы также не должны использовать его на С++. Назовите свои переменные, чтобы вы знали, для чего они нужны. Не называйте их дублировать информацию о типе, которую IDE может дать вам в любом случае и которая может измениться (и, как правило, не имеет значения. Если вы знаете, что что-то является счетчиком, то не имеет значения, является ли это int16, 32 или 64. Вы знаете, что он действует как счетчик, и поэтому любая операция, действительная на счетчике, должна быть действительной. Тот же аргумент для координат X/Y. Это координаты. Не имеет значения, являются ли они поплавками или удваивается. Возможно, важно знать, находится ли значение в единицах веса, расстояния или скорости. Не имеет значения, что это поплавок.).
На самом деле венгерская нотация появилась только как недоразумение. Изобретатель предполагал, что он будет использоваться для описания "концептуального" типа переменной (это координата, индекс, счетчик, окно?)
И люди, которые прочитали его описание, предположили, что под "типом" он имел в виду фактический тип языка программирования (int, float, string с нулевым завершением, указатель char)
Это никогда не было целью, и это ужасная идея. Он дублирует информацию, которую IDE может лучше предоставить, и которая не является во всех отношениях актуальной, поскольку она побуждает вас программировать на максимально возможном уровне абстракции.
Так почему? Я единственный человек, который
m_strExePathилиm_iNumberв моем С# код?
Нет. К сожалению нет. Скажите, что было бы exePath, если бы это была не строка? Почему я, как читатель вашего кода, должен знать, что это строка? Разве недостаточно знать, что это путь к исполняемому файлу? m_iNumber просто плохо назван. какое число это? Для чего это? Вы только что сказали мне дважды, что это число, но я до сих пор не знаю, что это за значение.
Ты, конечно, не единственный человек, но я надеюсь, что ты часть тенденции снижения:)
Проблема с венгерской нотацией заключается в том, что она пытается внедрить систему типов с помощью соглашений об именах. Это очень проблематично, потому что это система типов с только проверкой человеком. Каждый человек в проекте должен согласиться с одним и тем же набором стандартов, выполнять строгие проверки кода и обеспечивать, чтобы всем новым типам был присвоен соответствующий и правильный префикс. Короче говоря, невозможно гарантировать согласованность с достаточно большой базой кода. На данный момент нет согласованности, почему вы это делаете?
Кроме того, инструменты не поддерживают венгерскую нотацию. Это может показаться глупым комментарием на поверхности, но, например, рассмотрите рефакторинг. Каждый рефакторинг в венгерской системе соглашений об именах должен сопровождаться массовым переименованием для обеспечения сохранения префиксов. Массовые переименования восприимчивы ко всем видам тонких ошибок.
Вместо того, чтобы использовать имена для реализации системы типов, просто полагайтесь на систему типов. Он имеет автоматическую проверку и поддержку инструмента. Более новая среда IDE облегчает поиск типа переменной (intellisense, подсказки наведения и т.д.) И действительно устраняет первоначальное желание венгерской нотации.
Один недостаток венгерской нотации заключается в том, что разработчики часто меняют тип переменных во время раннего кодирования, что также требует изменения имени переменной.
если вы не используете текстовый редактор, а не VS IDE, для венгерской нотации мало значения, и он изменяет, а не улучшает читаемость.
Реальная ценность в венгерской нотации восходит к программированию на языке C и слабо типизированной природе указателей. В принципе, в тот же день самым простым способом отслеживания типа было использование венгерского языка.
В таких языках, как С#, система типов сообщает вам все, что вам нужно знать, и среда IDE представляет это вам очень удобным для пользователя способом, поэтому просто не нужно использовать венгерский язык.
По уважительной причине, чтобы не использовать его, ну есть немало. Во всяком случае, в С# и, если на то пошло С++ и многие другие langause, вы часто создаете свои собственные типы, так что будет венгерским для типа "MyAccountObject"? Даже если вы можете принять решение о разумных венгерских нотациях, это все еще заставляет фактическое имя переменной читать немного сложнее, потому что вам нужно пропустить "LPZCSTR" (или что-то еще) в начале. Более важным является стоимость обслуживания, хотя, что, если вы начинаете со Списка и переходите к другому типу коллекции (что-то, что я сейчас делаю много)? Затем вам нужно переименовать все переменные, которые используют этот тип, и все они не имеют реальной выгоды. Если бы вы просто использовали достойное имя для начала, вам не пришлось бы об этом беспокоиться.
В вашем примере, что, если вы создали или использовали какой-то более значимый тип для хранения пути (например, Path), вам тогда нужно изменить m_strExePath на m_pathExePath, что является болью, и в этом случае на самом деле очень полезно.
Только две области, где я вижу в настоящее время любую венгерскую нотацию:
_someVar)btn для кнопки, lbl для метки и т.д.)Ведущее подчеркивание в переменных-членах похоже на то, что мы должны оставаться с нами еще некоторое время, но я ожидаю, что популярность венгерских имен управления уменьшится.
Если венгерская нотация глубоко в вашей, вашей команде и сердце вашей компании, обязательно используйте ее. Это больше не считается лучшей практикой, насколько я могу читать блоги и книги.
Если вы удерживаете указатель на переменную в VS, она сообщит вам, какой тип переменной она есть, поэтому нет причин идти с этими именами криптовальных переменных, esp, поскольку люди, которые приходят с других языков, возможно, потребуется поддерживать код, и это будет препятствием для легкого чтения.
Большинство венгерских обозначений описывает, что такое переменная (указатель или указатель на указатель, или содержимое указателя и т.д.), и то, на что оно указывает (строка и т.д.).
Я нашел очень мало смысла для указателей на С#, особенно, когда нет неуправляемых/вызываемых вызовов. Кроме того, нет возможности использовать void *, поэтому нет необходимости в том, чтобы венгерский язык описывал его.
Единственное, что осталось от венгерского, что я (и большинство других на земле С#) использовать, состоит в том, чтобы предать частные поля _, как в _customers;
На языке, таком как С#, где многие ограничения по длине имени переменной не существуют, которые когда-то были на таких языках, как C и С++, и где IDE обеспечивает отличную поддержку для определения типа переменной, венгерская нотация является избыточной.
Код должен быть понятным, поэтому имена, такие как m_szName, могут быть заменены на this.name. И m_lblName может быть именемLabel и т.д. Важная вещь - быть последовательной и создавать код, который легко читать и поддерживать - это цель любого соглашения об именах, поэтому вы всегда должны решать, какое соглашение вы используете на основе этого. Я чувствую, что венгерская нотация не самая читаемая или самая удобная, потому что она может быть слишком краткий, требует определенного объема знаний о том, что означает префиксы, и не является частью языка, и поэтому ее трудно обеспечить и трудно обнаружить когда имя больше не соответствует базовому типу.
Вместо этого мне нравится заменять приложения Hungarian (префиксы типа m_), ссылаясь на this для членов, ссылаясь на имя класса для статических переменных и без префикса для локальных переменных. И вместо System Hungarian (включая тип переменной в имени переменной), я предпочитаю описывать, что такое переменная, например nameLabel, nameTextBox, count и databaseReference.
В какой-то момент у вас, вероятно, будет свойство
public string ExecutablePath { ... }
(не то, что вы должны стараться избегать аббревиатур типа "Exe" ). В этом случае ваш вопрос может быть спорным в значительной степени, поскольку вы можете использовать авто-свойства С# 3.0
public string ExecutablePath { get; set; }
вам больше не нужно указывать имя для переменной хранилища. Нет имени, нет вопросов/дискуссий о соглашениях об именах.
Очевидно, что автоматически реализованные свойства не всегда подходят.
Это зависит.
Является ли это достаточно значительным, чтобы добавить описание типа данных в имя переменной/объекта в вашем методе/классе?
Системная венгерская нотация > Приложения Венгерская нотация
Если вы разрабатываете процедурный язык (например, C), который имеет множество глобальных переменных или/и более низкий API, который имеет дело с точными типами и размерами данных (например, C <stdint.h>, где для записи более 40 различных типов данных используются описать int), системная венгерская нотация более полезна.
Обратите внимание, однако, что многие современные программисты считают, что добавление информации о типе в имени переменной изобилует, поскольку многие из современных IDE имеют очень удобные инструменты (например, Outline Eclipse, Symbol Navigator Xcode, Visual AssistX для Visual Studio и т.д.). Системная венгерская нотация широко использовалась в раннем возрасте в программировании (например, FORTRAN, C99), когда информация о типе была недоступна в качестве инструмента для IDE.
Системная венгерская нотация < Приложения Венгерская нотация
Если вы работаете в классе или методе более высокого уровня (например, определяемый пользователем класс/метод драйвера для вашего приложения С#), запись простого типа данных может быть недостаточной для описания переменной/объекта. Поэтому в этом случае мы используем венгерскую ноту Apps.
Например, если целью вашего метода является получение исполняемого пути и отображение сообщения об ошибке, если оно не найдено, вместо того, чтобы отметить, что это тип string, мы отмечаем более значимую информацию для описания переменной/объект для программистов, чтобы лучше понять цель переменной /obejct:
private string mPathExe;
private string msgNotFound;
Это об эффективности. Сколько времени было потрачено впустую, присвоив неправильное значение переменной. Наличие точных деклараций переменных - это повышение эффективности. Это о читаемости. Это о соблюдении существующих моделей. Если вы хотите творчества, выполните дизайн пользовательского интерфейса, выполните системную архитектуру. Если ваше программирование, оно должно быть спроектировано, чтобы облегчить вам работу членов команды: не ваш. 2% прироста эффективности - дополнительная неделя каждый год. Это 40 часов. Повышение производительности труда человека достигается повышением эффективности.
Венгерская нотация нашла свое первое основное использование с BCPL языком программирования. BCPL является коротким для языка программирования C и является древним (разработанным в 1966 году) беспричинным языком, где все является словом. В этой ситуации венгерская нотация может помочь в проверке типа "голой глаз".
С тех пор прошло много лет...
Вот какая последняя документация ядра Linux (по состоянию на 2016) говорит (смелый мой):
Кодирование типа функции в названии (так называемый венгерский нотация) поврежден мозгом - компилятор знает типы в любом случае и может проверьте эти, и это только смущает программиста.
Также обратите внимание, что есть два типа венгерских обозначений:
Системы венгерской нотации: префикс кодирует физический тип данных.
Приложения Венгерская нотация. Префикс кодирует логический тип данных.
Системы Венгерская нотация больше не рекомендуется из-за избыточности проверки типов, что, в свою очередь, связано с продвижением в возможностях компилятора. Тем не менее, вы все равно можете использовать венгерскую нотацию приложений, если компилятор не проверяет для вас типы логических данных. Как правило, венгерская нотация хороша тогда и только тогда, когда она описывает семантику, которая недоступна в противном случае.