В моей нынешней работе нет руководств по кодированию. Каждый в значительной степени кодирует так, как он хочет. Что хорошо, так как компания маленькая.
Однако недавно один новый парень предложил всегда использовать венгерскую нотацию. До сих пор некоторые из нас использовали какую-то венгерскую нотацию, а некоторые нет. Вы знаете, это инжиниринговая компания, поэтому стили кодирования не имеют большого значения, если алгоритмы надежны.
Лично я чувствую, что эти маленькие сокращения типа являются излишними. Хорошо продуманное имя обычно дает одно и то же сообщение. (Кроме того, большая часть нашего кода должна работать на некоторых чудовищных DSP, где концепция в любом случае нравится bool
или float
не существует).
Итак, как вы относитесь к венгерской нотации? Вы используете это? Зачем?
источник
Ответы:
Когда большинство людей говорят «Венгерская нотация», они на самом деле говорят о « Системном венгерском ».
Системы венгерского совершенно бесполезны и их следует избегать. Нет необходимости кодировать тип переменной в ее имени. Тем не менее, Systems Hungarian на самом деле является неправильным пониманием оригинального , «настоящего» венгерского: Apps Hungarian.
В Apps Hungarian вы не кодируете «тип» в имени переменной, вы кодируете «вид» переменной. Так что нет
nWidth
, ноpxWidth
илиemWidth
(для «ширины в пикселях» или «ширины в ems» соответственно). Не,strName
ноsName
илиusName
(для «безопасного имени» или «небезопасного имени» соответственно - полезно при приеме ввода от пользователей: небезопасные строки).Лично я обычно не беспокоюсь ни об этом. Если я не делаю что-то, что явно преобразует «вид» значения (например, я использовал префикс «px» и «em» в прошлом, потому что он делает ошибки вроде
pxArea = emWidth * emHeight
очевидными).См. Также статью Джоэла « Создание неправильного кода, выглядящего неправильно ».
источник
raw
rawUsername
s
это не дляstring
чего-то, а для "safe" (или я также слышал "safe string").МестоимениеВы глаголНе должно быть наречиеНеверный глаголИспользуйте прилагательноеГенгарское существительноеПримечание, предлогIt глаголОбъединяет существительноеНазначительное наречиеСравнительноКлагательное прилагательноеHard infinitiveTo verbRead.
источник
Во-первых:
Стили кодирования имеют значение независимо от компании. Да, алгоритмы должны быть надежными, но код должен обслуживаться всеми, а не только первоначальным разработчиком. Наличие стандарта кодирования, который включает в себя элементы стиля, помогает достичь этого. Я не говорю, что весь код должен быть идентичен по стилю - это будет контрпродуктивно, но должна быть степень согласованности.
Теперь на венгерской нотации:
Несмотря на то, что он имел свои применения, в современной среде IDE, которая поддерживает поведение типов IntelliSense, нет необходимости включать тип переменной в ее имя. Эта информация доступна вам другими способами. В худшем случае это может усложнить чтение кода, если в будущем вам придется изменить тип переменной.
источник
Не используйте это. Это избыточно и затрудняет чтение кода.
источник
Большая часть дебатов о (Системной) Венгерской Нотации зависит от области работы. Раньше я был очень тверд на стороне «ни за что!», Но, проработав несколько лет в компании, где он используется для разработки встраиваемых систем, я вижу некоторые преимущества этого в некоторых приложениях, и он определенно вырос на мне ,
Системы венгерские
Из того, что я могу сказать, Systems Hungarian часто используется во встроенной области. В приложениях для ПК компилятор будет иметь дело со многими проблемами, связанными с различиями (например) строк, целых чисел и значений с плавающей запятой. На глубоко внедренной платформе вас чаще всего волнуют различия между 8-разрядными целыми числами без знака, 16-разрядными целыми числами со знаком и т. Д. Компилятор (или даже ограничение с применением принудительных правил MISRA) не всегда улавливает их. В этом случае полезно иметь имена переменных
u8ReadIndex
,s16ADCValue
например,.Apps Hungarian
Apps венгерский имеет определенные преимущества, когда речь идет о приложениях для ПК / веб, например, предлагая визуальное различие между «небезопасными» строками и «безопасными» строками (т. Е. Теми, которые были введены пользователем, и теми, которые были экранированы или прочитаны из внутренних ресурсов или чем-то еще). ). Компилятор не знает об этом различии.
В чем смысл?
Использование (систем или приложений) венгерского - это неправильный код .
Если вы копируете небезопасную строку прямо в безопасную строку без какой-либо экранировки, это будет выглядеть неправильно, если вы используете Apps Hungarian.
Если вы умножаете целое число со знаком на целое число без знака, компилятор будет (часто молча) преобразовывать подписанное в (возможно, огромное) беззнаковое, что может привести к ошибке: Systems Hungarian делает этот взгляд неправильным.
В обеих этих ситуациях венгерская нотация (приложения / системы) имеет тенденцию ускорять формальные проверки кода, поскольку меньше ссылок на тип переменной.
В целом
В целом, я считаю, что самое главное, чтобы у вас был стандарт кодирования. Использует ли это Systems Hungarian, Apps Hungarian или нет, это вопрос личных или групповых предпочтений, во многом как выбор типов отступов и т. Д. Однако у всей команды разработчиков есть определенные преимущества, работающие с одинаковыми предпочтениями.
источник
Целью венгерской нотации является кодирование информации в идентификатор, который иначе не может быть закодирован в системе типов. Мое собственное мнение таково: если эта информация достаточно важна для ее кодирования, то она достаточно важна для кодирования в системе типов, где ее можно должным образом проверить. И если информация не важна, то какого чёрта вы хотите загромождать ее исходным кодом?
Или, если выразиться более кратко: информация о типе принадлежит системе типов. (Примечание: это не обязательно должна быть статическая система типов. Пока она отлавливает ошибки типов, мне все равно, когда они их отлавливают.)
В нескольких других ответах упоминаются единицы измерения в качестве допустимого использования венгерской нотации. (Я немного удивлен, что никто еще не упомянул космический орбитальный аппарат НАСА «Марс», поскольку, похоже, это все время обсуждается в Венгерской нотации).
Вот простой пример на F #:
Смотри, мама, не венгры!
Если бы я был использовать венгерскую нотацию вместо типов здесь, это не помогло бы мне один бит:
Компилятор пропустил это. Теперь я полагаюсь на человека, который определит, что по сути является ошибкой типа. Разве это не то, для чего нужна проверка типов?
Еще лучше, используя язык программирования Frink :
Итак, в заключение: я не люблю венгерские обозначения. Вы никогда не должны использовать это.
При этом, я думаю, что использование венгерской нотации - хорошая идея. Чего ждать?
Да! В данном конкретном случае вы упомянули:
Но это как раз единственный разумный вариант использования для венгерской нотации!
PS: я искренне рекомендую посмотреть на Фринка. Его руководство содержит некоторые из самых удивительных шуток пердеть когда-либо. Это также довольно крутой язык :-)
источник
typedef meter float
...Это не имеет смысла в объектно-ориентированном языке - все это тип, который очевиден при попытке его использовать.
источник
Единственное место, где Systems Венгерский используется, это язык со слабой типизацией, такой как C. Это вдвойне важно для C, потому что нет явного объекта (он имеет структуры, но все функции являются внешними по отношению к структуре). В чем-то более строго типизированном, например в C ++, Java и C #, это не помогает, а на самом деле ухудшает ситуацию. Код изменяется, и изменить тип намного проще, чем изменить все места, где вы используете имя переменной. Это также ненужная занятая работа, которая имеет тенденцию игнорироваться.
Если у вас есть единицы измерения, это может помочь закодировать это в названии, но, в конце концов, это также может быть дополнительным шумом. Например, мы объявим стандартную единицу измерения для различных вещей, с которыми мы работаем в нашем коде. Например, мы используем градиенты или градусы, метры или футы, кадры или миллисекунды? Как только стандарт установлен для кода, каждый раз, когда мы читаем одну единицу измерения, мы всегда немедленно конвертируем в стандартную единицу измерения для кода.
Мой совет : начните с ваших текущих проблем и выберите разумный стандарт для этой части кода. Слишком конкретизировать стандарт кодирования контрпродуктивно. Есть большая ценность иметь имена переменных и полей, которые объясняют, что они представляют, и большую часть времени вы можете безопасно вывести тип из концепции.
источник
ЧЕРТ ВОЗЬМИ НЕТ!
Не используйте венгерскую запись или любую другую запись. Как программисты, мы не должны использовать «нотацию» для имен наших переменных.
То, что мы должны сделать, это правильно назвать наши переменные :
z
когда это переменная класса, представляющая именованный объект, скажем, счет за телефон. Назовите этоphoneBill
илиPhoneBill
.Избегайте слишком конкретных имен. Когда что-то ясно без дополнительной информации, не включайте это. Если это просто строковая индексная переменная для циклического перебора символов строки, и вы используете ее только один раз в функции MyFunc, с какой стати вы когда-либо вызывали бы ее
MyFuncTempStringCharacterIndex
? Это грустная шутка. ПозвониPos
или дажеi
если хочешь. В контексте следующий программист легко поймет, что это значит.Обращая внимание на то, насколько общим или конкретным должно быть имя, рассмотрите домен, в котором оно находится, и контекст других возможных значений. В узком случае, когда есть два легко запутанных, одинаковых элемента типа, которые используются одинаковым образом, хорошо бы придумать префикс или суффикс, чтобы обозначить это различие. Держите это как можно короче.
Как говорили другие авторы, именно этот узкий случай запустил «Apps Hungarian», чтобы различать измерения относительно окна
rwTabPosition
и относительно документаrdTabPosition
. Но в приложении, которое делает все относительно документа, не добавляйте лишних слов! На самом деле, почему бы не использовать идею Йорга В. Миттага о создании из нее действительно нового типа? Тогда вы не можете все перепутать.Практически в любой области добавление материала с минимальной плотностью значений снижает общую значимость и упрощает понимание. Вот один пример от Бена Франклина . И еще один пример: на английском можно украсить наши слова своей частью речи. Это больше информации, не так ли? Если новички в английском путаются, это может быть им действительно полезно, верно? Прочитайте это и скажите мне, насколько вы думаете, что это полезно для долгосрочного понимания и эффективного распространения информации:
При добавлении информации, я сделал , что полная боль читать.
Так что забудьте об обозначениях. Забудьте специальные префиксы, которые вы всегда добавляете. На мой взгляд, единственное реальное руководство здесь должно быть:
источник
Назначение идентификатора важнее его типа. Если вы используете описательные имена для идентификаторов в своих программах, вам не нужно использовать венгерские обозначения.
isConnected
всегда читабельнее и понятнее, чемboolConnected
.источник
Когда я был программистом на С ++, мы использовали венгерский язык, и это было здорово. Вы могли видеть тип переменной (например, BSTR, CString, LPCTSTR или char *) без поиска объявления. В те дни вы искали декларацию, выполняя:
Так что это имело значение совсем немного. Но где-то около 2000 года произошло несколько вещей:
lastName
это такSystem.String
, потому что есть только один строковый класс.Я был одним из последних, кто отказался от венгерского языка, и теперь, когда я читаю старый исходный код, это действительно раздражает меня.
источник
Я просто ненавижу венгерскую нотацию, я предпочитаю использовать подчеркивание для разделения имен переменных.
Кроме того, когда вы вводите тип в качестве первой буквы в начале имени вашей переменной, как это: float fvelocity; vect vDirection; строка ** ppszWord;
автозаполнение сортирует их все, и у вас возникают проблемы с поиском того, что вы хотите, и люди склонны использовать то, что они считают лучше, и это уже не нотация.
Мне просто нравится писать ThingsLikeThat, когда мне нужно очень описательно описать переменную, потому что она экономит место, а наличие заглавных букв делает ее более читабельной.
Что я обычно делаю, так это называю мои методы и классы, где первая буква должна быть Uppercase, а строчная - для имен переменных, а также подчеркивание для имен переменных (я считаю, что последняя полезна).
Серьезно, я предпочитаю, чтобы люди заботились об этих правилах: используйте запятые, арифметику и фигурные скобки с соответствующими пробелами:
Не более 80 символов в строке или по крайней мере 90 символов используют многострочные аргументы для функций или long
if
:источник
Согласитесь с большинством, это старый стиль.
В современных IDE быстрое наведение на переменную показывает тип.
источник