Ви префікс імен змінних з абревіатурою типів змінних? (Угорська нотація) [закрито]

У моїй теперішній роботі немає інструкцій щодо кодування. Кожен майже кодує так, як хоче. Що добре, оскільки компанія невелика.

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

Особисто я відчуваю, що ці невеликі скорочення типу є надлишковими. Добре продумане ім’я зазвичай передає те саме повідомлення. (Крім того, більша частина нашого коду повинна працювати на деяких дивних DSP, де таке поняття, як boolі floatне існує).

Отже, як ви ставитесь до угорської нотації? Ви цим користуєтесь? Чому?

Коли більшість людей кажуть "Угорська нотація", вони насправді говорять про " Угорська система ".

Системи Угорська абсолютно марні і цього слід уникати. Немає необхідності кодувати тип змінної у своєму імені. Однак Система Угорська насправді є непорозумінням оригінальної , "справжньої" угорської мови: Apps Hungarian.

В Угорській програмі ви не кодуєте "type" в назві змінної, ви кодуєте "kind" змінної. Так не nWidth, але pxWidthабо emWidth(для "ширина в пікселях" або "ширина в ем" відповідно). Не, strNameале sNameабо usName(для "безпечного імені" або "небезпечного імені" відповідно - корисно при прийнятті даних від користувачів: небезпечні рядки).

Особисто я ні з ким не турбуюсь. Якщо я не роблю щось, що явно перетворює "вид" значення (наприклад, я раніше використовував префікс "px" і "em", оскільки це робить помилки, як pxArea = emWidth * emHeightочевидні).

Дивіться також статтю Джоела " Зробити неправильний код невірним ".

займенникВи дієсловоМожливо прислівникБільше дієсловаВикористовувати прикметникГунгарський іменникНотація, прийменникІннє дієсловоЗаймається колективним іменникомВсі всякий прислівникСоставний прикметКловий прикметникЗахисний інфінітивTo дієсловоПрочитати.

По-перше:

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

Стилі кодування мають значення незалежно від компанії. Так, алгоритми повинні бути здоровими, але код повинен бути доступним для всіх, а не лише оригінальним розробником. Наявність стандарту кодування, що включає елементи стилю, певним чином досягає цього. Я не кажу, що весь код повинен бути однаковим за стилем - це було б дуже продуктивно, але має бути певна послідовність.

Тепер на позначення угорської мови:

Незважаючи на те, що він користувався, сучасний IDE, що підтримує поведінку типу IntelliSense, не повинен включати тип змінної у своє ім’я. Ця інформація доступна для вас іншими способами. У гіршому випадку це може зробити код важче читати, якщо вам доведеться в майбутньому змінити тип змінної.

Не використовуйте його. Це зайве і робить код важче читати.

Дуже багато дебатів щодо (системної) угорської нотації залежить від сфери роботи. Раніше я був дуже твердо на боці "ніякого способу!", Але, працюючи кілька років у компанії, де вона використовується для вбудованої розробки, я можу побачити деякі переваги цього в певних програмах, і це напевно виросло на мені .

Системи угорські

З того, що я можу сказати, Система Угорська, як правило, багато використовується у вбудованому полі. У програмах для ПК компілятор вирішить багато питань, пов’язаних з різницею між (наприклад) рядками, цілими числами та значеннями з плаваючою комою. На глибоко вбудованій платформі вас частіше турбують відмінності між 8-бітовими цілими числами, які не підписуються, 16-бітовими цілими числами тощо. В цьому випадку із змінними іменами , як u8ReadIndex, s16ADCValueможе бути корисним.

Програми угорські

Угорські програми мають певні переваги, коли мова йде про ПК / веб-додатках, наприклад, пропонуючи візуальну різницю між "небезпечними" рядками та "безпечними" рядками (тобто тими, що введені користувачем, і тими, які були врятовані чи прочитані з внутрішніх ресурсів чи будь-чого іншого ). Укладач не знає про цю відмінність.

У чому справа?

Використання (Системи або Програми) угорської мови полягає в тому, щоб неправильний код виглядав неправильно .

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

Якщо ви множите підписане ціле число на безпідписане ціле число, компілятор (часто мовчки) просуває підписаний до (можливого величезного) безпідписаного, можливо, що призведе до помилки: Система Угорська робить це виглядає неправильним.

В обох цих ситуаціях угорська нотація (Apps / Systems) має тенденцію до швидшого перегляду офіційного коду, оскільки менше посилається на тип змінної.

Загалом

В цілому, на мою думку, найголовніше, що у вас є стандарт кодування. Чи використовуються вони угорські системи, угорські програми чи ні одне - це питання особистого чи групового уподобання, як і вибір типів відступів тощо. Однак є певна перевага для всієї команди розробників, яка працює на ті самі переваги.

Мета угорської нотації - це кодування інформації в ідентифікатор, який інакше не може бути закодований в системі типів. Моя власна думка полягає в тому, що якщо ця інформація є достатньо важливою для кодування, то це досить важливо, щоб вона була закодована в системі типів, де її можна правильно перевірити. А якщо інформація неважлива, то чому, чортів, ви хочете захаращувати її вихідним кодом?

Або, простіше кажучи: інформація про тип належить до системи типів. (Примітка: вона не повинна бути системою статичного типу. Поки вона вловлює помилки типу, мені все одно, коли вони їх ловлять.)

Кілька інших відповідей згадали одиниці вимірювання як прийнятне використання угорської нотації. (Я дуже здивований, що ще ніхто не згадав про НАСА Марс Клімат Орбітер, оскільки, здається, це постійно виникає в дискусіях про Угорську нотацію).

Ось простий приклад у 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: Від усієї душі рекомендую поглянути на Frink. Посібник містить деякі найдивовижніші жартівливі приколи. Це також досить класна мова :-)

Це не має сенсу в об'єктно-орієнтованій мові - все це тип, який очевидний при спробі його використовувати.

Єдине місце, де надаються Системи Угорська мова, є слабко набраною мовою, як C. Це вдвічі важливо для C, оскільки немає явного об'єкта (він має структури, але всі функції зовнішні для структури). У чомусь більш сильному набраному вигляді, наприклад, C ++, Java та C #, це не допомагає, а насправді стає гірше. Код змінюється, і змінити тип набагато простіше, ніж змінити всі місця, де ви використовуєте ім’я змінної. Це також зайва зайнятість, яка, як правило, ігнорується.

Якщо у вас є одиниці вимірювання, це може допомогти кодувати це в імені, але в кінцевому підсумку це також може бути зайвим шумом. Наприклад, ми оголосимо стандартну одиницю вимірювання для різних речей, з якими ми працюємо у своєму коді. Наприклад, ми використовуємо градієнти або градуси, метри або фути, рамки або мілісекунди? Після встановлення стандарту для коду, кожного разу, коли ми читаємо в одній одиниці вимірювання, ми завжди негайно перетворюємо на стандартну одиницю вимірювання для коду.

Моя порада : почніть з ваших поточних больових точок і виберіть розумний стандарт для цієї частини коду. Перевизначення стандарту кодування є контрпродуктивним. Існує велика цінність у наявності імен змінних та полів, які визначають, що вони представляють, і більшу частину часу ви можете сміливо виводити тип із концепції.

НЕ БУДЕТ!

Не використовуйте угорські позначення чи будь-які інші позначення. Як програмісти, ми не повинні використовувати "позначення" для наших імен змінних.

Що ми повинні зробити, це добре назвати наші змінні :

• Уникайте занадто загальних назв. Не називайте його, zколи це змінна категорія, яка представляє названий об'єкт, скажімо, телефонний рахунок. Назвіть це phoneBillабо PhoneBill.

• Уникайте занадто конкретних імен. Коли щось зрозуміло без додаткової інформації, не включайте його. Якщо це просто змінна індексна зміна для перегляду символів рядка, і ви використовуєте її лише один раз у функції MyFunc, чому б на землі ви її колись називали MyFuncTempStringCharacterIndex? Це сумний жарт. Телефонуйте Posабо навіть, iякщо вам подобається. У контексті наступний програміст легко зрозуміє, що це означає.

• Здійснюючи нульове значення щодо того, яким має бути загальне чи конкретне ім’я, врахуйте домен, в якому він знаходиться, та контекст інших можливих значень. У вузькому випадку, коли є два елемента, що легко сплутати, схожих типів, які використовуються однаково, тоді добре позначити цю різницю з префіксом або суфіксом. Тримайте це якомога коротше.

Як говорили інші відповіді, саме цей вузький випадок, який розпочав "Apps Hungarian", розрізняв вимірювання щодо вікна rwTabPositionта відносно документа rdTabPosition. Але у програмі, яка робить усе, що стосується документа, не додайте зайвої суворості! Насправді, чому б не використати ідею Йорга У Міттага про створення нового фактичного типу? Тоді ви не можете змішати речі.

Практично в будь-якій області додавання матеріалів, що мають мінімальну щільність значень, знижує загальну осмисленість та легкість розуміння. Ось один приклад від Бена Франкліна . І ще один приклад: англійською можна прикрасити наші слова своєю частиною мови. Це більше інформації, чи не так? У випадку, якщо новачки в англійській мові заплутаються, це може бути їм дуже корисно, правда? Прочитайте це та скажіть, наскільки корисним ви вважаєте це для тривалого розуміння та ефективного внесення інформації:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. prepAs nouprogrammers, prowe vrbshould advnot verbe nouusing "nounotation" prpfor proour пристосовні іменники.

При додаванні інформації, я зробив , що повна біль читати.

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

Зберігайте назви змінних якомога коротше , наскільки значущі та завжди однозначні .

Призначення ідентифікатора важливіше, ніж його тип. Якщо ви використовуєте описові імена для ідентифікаторів у своїх програмах, вам не потрібно використовувати угорські позначення. isConnectedзавжди читабельніший і легший для розуміння, ніж boolConnected.

Ми використовували угорську, коли я був програмістом на C ++, і це було чудово. Ви можете бачити тип змінної (fe BSTR, CString, LPCTSTR або char *), не шукаючи декларації. У ті дні ви шукали декларацію, зробивши:

1. ctrl-home
2. ctrl-F
3. назва змінної
4. увійти

Тож це мало значення. Але десь близько 2000 року трапилося кілька речей:

• редактори стали досить розумними, щоб відображати тип змінної як підказку
• редактори мали ярлик "перейти до декларації" та швидкий спосіб перегляду назад
• С ++ використовувалося менше, і більшість інших мов мають менш змінні типи. Наприклад, у C # ви майже впевнені, що lastNameце a System.String, оскільки існує лише один клас рядків.

Я був одним з останніх, хто відмовився від угорської мови, і тепер, коли я читав старий вихідний код, він насправді дратує.

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

Крім цього, коли ви ставите тип як першу букву на початку імені змінної так: float fvelocity; vect vDirection; рядок ** ppszWord;

автодоповнення сортує їх усіх, і у вас виникають проблеми з тим, що ви хочете, і люди, як правило, використовують те, що, на їхню думку, краще, і це вже не нотація.

Мені просто подобається писати ThingsLikeThat, коли мені потрібно бути дуже описовим щодо змінної, оскільки це економить простір, а факт, що є кришки, робить його більш читабельним.

Зазвичай я називаю свої методи та класи, причому перша літера є верхньою літерою, а маленька - для змінних імен, а підкреслення - для змінних імен (я вважаю цю останню корисною).

Я серйозно віддаю перевагу людям піклуватися про ці правила: Використовуйте коми, арифметичні та дужки з відповідними пробілами:

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

Не більше 80 знаків на рядок або НА МОСТУ 90 символів, використовуйте багаторядкові аргументи для функцій або довго if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

Погодьтеся з більшістю, це старий стиль.

У сучасних програмах IDE швидке наведення курсора на змінну показує тип.