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

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

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

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

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

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

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

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

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

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

МестоимениеВы глаголНе должно быть наречиеНеверный глаголИспользуйте прилагательноеГенгарское существительноеПримечание, предлог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 #:

[<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: я искренне рекомендую посмотреть на Фринка. Его руководство содержит некоторые из самых удивительных шуток пердеть когда-либо. Это также довольно крутой язык :-)

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

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

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

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

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

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

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

• Избегайте слишком общих имен. Не называйте его, 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 приставляемых имен.

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

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

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

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

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

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

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

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

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

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

Кроме того, когда вы вводите тип в качестве первой буквы в начале имени вашей переменной, как это: 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)
)

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

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