Вы префикс имени переменных с сокращением типов переменных? (Венгерская запись) [закрыто]

37

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

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

Лично я чувствую, что эти маленькие сокращения типа являются излишними. Хорошо продуманное имя обычно дает одно и то же сообщение. (Кроме того, большая часть нашего кода должна работать на некоторых чудовищных DSP, где концепция в любом случае нравится boolили floatне существует).

Итак, как вы относитесь к венгерской нотации? Вы используете это? Зачем?

bastibe
источник
См. Также: programmers.stackexchange.com/questions/14789/…
Kramii Восстановите Монику
7
Какой язык программирования вы используете?
Ларри Коулман
3
На самом деле это не хорошо - у вас должен быть стандарт кодирования (формальный или иной), по моему мнению, это никогда не хорошо ... но другие могут не согласиться.
Murph
@Larry: мы используем в основном C и C ++, с небольшим количеством ассемблера и Lua здесь и там.
Бастиб
11
@Paperflyer, стандарты / правила кодирования не для клиентов, а для команды разработчиков. Если вы не уверены, что одни и те же разработчики будут работать вечно (нереально), я твердо верю, что вы должны установить и соблюдать стандарты кодирования. Это приводит к созданию более обслуживаемых систем, ускоряет работу новых сотрудников и повышает согласованность. При этом я согласен с тем, что венгерские обозначения оказались излишними и являются скорее пережитком прошлого. Хорошо продуманные имена более важны, особенно в связи с тем, что в наши дни используются гораздо более мощные IDE.
Марк Фридман

Ответы:

77

Когда большинство людей говорят «Венгерская нотация», они на самом деле говорят о « Системном венгерском ».

Системы венгерского совершенно бесполезны и их следует избегать. Нет необходимости кодировать тип переменной в ее имени. Тем не менее, Systems Hungarian на самом деле является неправильным пониманием оригинального , «настоящего» венгерского: Apps Hungarian.

В Apps Hungarian вы не кодируете «тип» в имени переменной, вы кодируете «вид» переменной. Так что нет nWidth, но pxWidthили emWidth(для «ширины в пикселях» или «ширины в ems» соответственно). Не, strNameно sNameили usName(для «безопасного имени» или «небезопасного имени» соответственно - полезно при приеме ввода от пользователей: небезопасные строки).

Лично я обычно не беспокоюсь ни об этом. Если я не делаю что-то, что явно преобразует «вид» значения (например, я использовал префикс «px» и «em» в прошлом, потому что он делает ошибки вроде pxArea = emWidth * emHeightочевидными).

См. Также статью Джоэла « Создание неправильного кода, выглядящего неправильно ».

Дин Хардинг
источник
2
Посмотрите на сочинения Симони по этому вопросу: он - оригинальный пропагандист венгерского языка, и его версия является той, которая полезна. msdn.microsoft.com/en-us/library/aa260976(v=vs.60).aspx
Майкл Кохн
1
Должен быть какой-то способ включить модули в пользовательский тип, если он вам действительно нужен (то же самое для безопасных / небезопасных строк). Тем не менее, я вижу, что при этом вы можете столкнуться с проблемами производительности (например, вы не захотите переносить класс в класс). В F # он вводит функцию единицы измерения, которая в основном добавляет дополнительную информацию о типе в удваивания, просто для этой цели.
Скотт Уитлок
1
В коде, rawrawUsername
имеющем
1
@ Скотт другой вариант будет строго типизированный typedef
jk.
1
@JBR: вы на самом деле читали ответ? В "Apps Hungarian" sэто не для stringчего-то, а для "safe" (или я также слышал "safe string").
31

МестоимениеВы глаголНе должно быть наречиеНеверный глаголИспользуйте прилагательноеГенгарское существительноеПримечание, предлогIt глаголОбъединяет существительноеНазначительное наречиеСравнительноКлагательное прилагательноеHard infinitiveTo verbRead.

smirkingman
источник
6
Заставил меня улыбнуться ... педантизм, но "к" это предлог, а не инфинитив. «читать» - это инфинитив.
DrAl
@Dral, конечно, это было в юмористическом регистре, а не в грамматическом уроде: D
ухмылка
1
Это было потрясающе, заставило меня смеяться. :)
Corv1nus
26

Во-первых:

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

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

Теперь на венгерской нотации:

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

ChrisF
источник
21

Не используйте это. Это избыточно и затрудняет чтение кода.

codeape
источник
8
Это хуже, чем «избыточный». В некоторых сложных ситуациях сложно разобраться. В частности, каждый из классов, которые вы определяете в своем приложении, нуждается в сокращении. После определения 20 или около того классов, вы из однобуквенных сокращений. Что теперь? Смесь из одной буквы и двух букв? Как насчет сложных ссылок на элемент структуры данных? Указатель на массив сопоставлений списков с сопоставлениями из целых чисел в строки? Как сокращение этого было бы полезно?
С.Лотт
13

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

Системы венгерские

Из того, что я могу сказать, Systems Hungarian часто используется во встроенной области. В приложениях для ПК компилятор будет иметь дело со многими проблемами, связанными с различиями (например) строк, целых чисел и значений с плавающей запятой. На глубоко внедренной платформе вас чаще всего волнуют различия между 8-разрядными целыми числами без знака, 16-разрядными целыми числами со знаком и т. Д. Компилятор (или даже ограничение с применением принудительных правил MISRA) не всегда улавливает их. В этом случае полезно иметь имена переменных u8ReadIndex, s16ADCValueнапример,.

Apps Hungarian

Apps венгерский имеет определенные преимущества, когда речь идет о приложениях для ПК / веб, например, предлагая визуальное различие между «небезопасными» строками и «безопасными» строками (т. Е. Теми, которые были введены пользователем, и теми, которые были экранированы или прочитаны из внутренних ресурсов или чем-то еще). ). Компилятор не знает об этом различии.

В чем смысл?

Использование (систем или приложений) венгерского - это неправильный код .

Если вы копируете небезопасную строку прямо в безопасную строку без какой-либо экранировки, это будет выглядеть неправильно, если вы используете Apps Hungarian.

Если вы умножаете целое число со знаком на целое число без знака, компилятор будет (часто молча) преобразовывать подписанное в (возможно, огромное) беззнаковое, что может привести к ошибке: Systems Hungarian делает этот взгляд неправильным.

В обеих этих ситуациях венгерская нотация (приложения / системы) имеет тенденцию ускорять формальные проверки кода, поскольку меньше ссылок на тип переменной.

В целом

В целом, я считаю, что самое главное, чтобы у вас был стандарт кодирования. Использует ли это Systems Hungarian, Apps Hungarian или нет, это вопрос личных или групповых предпочтений, во многом как выбор типов отступов и т. Д. Однако у всей команды разработчиков есть определенные преимущества, работающие с одинаковыми предпочтениями.

Dral
источник
Вы должны дать понять, на каких языках вы говорите. Поскольку вы работаете со встроенной разработкой, я предполагаю, что вы используете C? Венгерский имеет смысл в Си, но не в более современных языках.
JacquesB
9

Целью венгерской нотации является кодирование информации в идентификатор, который иначе не может быть закодирован в системе типов. Мое собственное мнение таково: если эта информация достаточно важна для ее кодирования, то она достаточно важна для кодирования в системе типов, где ее можно должным образом проверить. И если информация не важна, то какого чёрта вы хотите загромождать ее исходным кодом?

Или, если выразиться более кратко: информация о типе принадлежит системе типов. (Примечание: это не обязательно должна быть статическая система типов. Пока она отлавливает ошибки типов, мне все равно, когда они их отлавливают.)

В нескольких других ответах упоминаются единицы измерения в качестве допустимого использования венгерской нотации. (Я немного удивлен, что никто еще не упомянул космический орбитальный аппарат НАСА «Марс», поскольку, похоже, это все время обсуждается в Венгерской нотации).

Вот простой пример на F #:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

Смотри, мама, не венгры!

Если бы я был использовать венгерскую нотацию вместо типов здесь, это не помогло бы мне один бит:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

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

Еще лучше, используя язык программирования Frink :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

Итак, в заключение: я не люблю венгерские обозначения. Вы никогда не должны использовать это.

При этом, я думаю, что использование венгерской нотации - хорошая идея. Чего ждать?

Да! В данном конкретном случае вы упомянули:

Кроме того, большая часть нашего кода должна выполняться на некоторых чудовищных DSP, где такая концепция, как bool или float, в любом случае не существует.

Но это как раз единственный разумный вариант использования для венгерской нотации!


PS: я искренне рекомендую посмотреть на Фринка. Его руководство содержит некоторые из самых удивительных шуток пердеть когда-либо. Это также довольно крутой язык :-)

Йорг Миттаг
источник
Я бы проголосовал за это 50 раз, если бы мог.
Ларри Коулман
1
Очень интересный аргумент! Я мог бы просто попробовать это в моем текущем проекте. typedef meter float...
Бастиб
6

Это не имеет смысла в объектно-ориентированном языке - все это тип, который очевиден при попытке его использовать.

billy.bob
источник
6

Единственное место, где Systems Венгерский используется, это язык со слабой типизацией, такой как C. Это вдвойне важно для C, потому что нет явного объекта (он имеет структуры, но все функции являются внешними по отношению к структуре). В чем-то более строго типизированном, например в C ++, Java и C #, это не помогает, а на самом деле ухудшает ситуацию. Код изменяется, и изменить тип намного проще, чем изменить все места, где вы используете имя переменной. Это также ненужная занятая работа, которая имеет тенденцию игнорироваться.

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

Мой совет : начните с ваших текущих проблем и выберите разумный стандарт для этой части кода. Слишком конкретизировать стандарт кодирования контрпродуктивно. Есть большая ценность иметь имена переменных и полей, которые объясняют, что они представляют, и большую часть времени вы можете безопасно вывести тип из концепции.

Берин Лорич
источник
1
На самом деле, хорошие IDE (или плагины) обычно имеют довольно мощные возможности рефакторинга, которые могут легко менять имена переменных.
Бастиб
4
Понятно, но дополнительный шум в управлении версиями для смены имени тоже не помогает. Скажем так, добавленная стоимость не оправдывает накладные расходы на обслуживание.
Берин Лорич
будет зависеть от языка, а также у некоторых будет прямая поддержка строго типизированных UoM или строго типизированных typedefs
jk.
6

ЧЕРТ ВОЗЬМИ НЕТ!

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

То, что мы должны сделать, это правильно назвать наши переменные :

  • Избегайте слишком общих имен. Не называйте его, zкогда это переменная класса, представляющая именованный объект, скажем, счет за телефон. Назовите это phoneBillили PhoneBill.
  • Избегайте слишком конкретных имен. Когда что-то ясно без дополнительной информации, не включайте это. Если это просто строковая индексная переменная для циклического перебора символов строки, и вы используете ее только один раз в функции MyFunc, с какой стати вы когда-либо вызывали бы ее MyFuncTempStringCharacterIndex? Это грустная шутка. Позвони Posили даже iесли хочешь. В контексте следующий программист легко поймет, что это значит.

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

Как говорили другие авторы, именно этот узкий случай запустил «Apps Hungarian», чтобы различать измерения относительно окна rwTabPositionи относительно документа rdTabPosition. Но в приложении, которое делает все относительно документа, не добавляйте лишних слов! На самом деле, почему бы не использовать идею Йорга В. Миттага о создании из нее действительно нового типа? Тогда вы не можете все перепутать.

Практически в любой области добавление материала с минимальной плотностью значений снижает общую значимость и упрощает понимание. Вот один пример от Бена Франклина . И еще один пример: на английском можно украсить наши слова своей частью речи. Это больше информации, не так ли? Если новички в английском путаются, это может быть им действительно полезно, верно? Прочитайте это и скажите мне, насколько вы думаете, что это полезно для долгосрочного понимания и эффективного распространения информации:

vrbDo advnot vrbuse nouВенгерское существительное cnjor adjany рядом с существительным. prepAs nouprogrammers, prowe vrbs не должен рекомендовать глагол nousing с использованием «nounotation» prp для proour приставляемых имен.

При добавлении информации, я сделал , что полная боль читать.

Так что забудьте об обозначениях. Забудьте специальные префиксы, которые вы всегда добавляете. На мой взгляд, единственное реальное руководство здесь должно быть:

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

ErikE
источник
Это почти точно, что наши стандарты. Единственное отличие состоит в том, что мы предпочитаем Pascal Case, когда именуем вещи, чтобы заглавные буквы были постоянными.
DForck42
5

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

Мудассир
источник
2
Я абсолютно согласен! Это то, что они называют «App Hungarian», а не «System Hungarian».
Бастиб
@bastibe: Нет, это то, что они называют описательными именами. Apps Hungarian опирается на сокращения.
JacquesB
2

Когда я был программистом на С ++, мы использовали венгерский язык, и это было здорово. Вы могли видеть тип переменной (например, BSTR, CString, LPCTSTR или char *) без поиска объявления. В те дни вы искали декларацию, выполняя:

  1. Ctrl-дом
  2. Ctrl-F
  3. имя переменной
  4. войти

Так что это имело значение совсем немного. Но где-то около 2000 года произошло несколько вещей:

  • редакторы стали достаточно умными, чтобы отображать тип переменной в виде всплывающей подсказки
  • редакторы имели ярлык «перейти к объявлению» и быстрый способ просмотра назад
  • C ++ использовался меньше, и большинство других языков имеют меньше типов переменных. Например, в C # вы точно уверены , что lastNameэто так System.String, потому что есть только один строковый класс.

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

Andomar
источник
2

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

Кроме того, когда вы вводите тип в качестве первой буквы в начале имени вашей переменной, как это: float fvelocity; vect vDirection; строка ** ppszWord;

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

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

Что я обычно делаю, так это называю мои методы и классы, где первая буква должна быть Uppercase, а строчная - для имен переменных, а также подчеркивание для имен переменных (я считаю, что последняя полезна).

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

void f(int a, char b);
int a = b + 4 / (3 + 4);

Не более 80 символов в строке или по крайней мере 90 символов используют многострочные аргументы для функций или long if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)
jokoon
источник
1

Согласитесь с большинством, это старый стиль.

В современных IDE быстрое наведение на переменную показывает тип.

Ozz
источник
2
Я нахожу это (что помогает IDE) плохим аргументом - когда вы кодируете, да, вы получите эту выгоду. Но существует множество случаев (фиксация, рецензирование, изменение / обвинение и т. Д.), Когда вам может не хватать этой поддержки.
Murph
Вы не правы !!!!! ;) Справедливо, я все равно не буду использовать венгерский!
Оз