Яке звернення до системи Угорська? [зачинено]

У яких рекомендаціях щодо іменування ви дотримуєтесь? , автор каже:

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

Я зіткнувся з кількома програмістами, які все ще вважають за краще використовувати угорську, переважно в угорському стилі Petzold / Systems. Подумайте dwLength = strlen(lpszName).

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

Чому програмісти все ще наполягають на використанні цього стилю позначення? Це просто інерція? Чи є якісь переваги, які переважують зниження читабельності? Люди просто вчаться ігнорувати декораторів під час читання коду, і якщо так, то як вони продовжують додавати вартість?

EDIT: Дуже багато відповідей пояснюють історію, або чому вона більше не актуальна, обидві вони висвітлені в статті, яку я цитував.

Мені дуже хотілося б почути від когось там, хто все ще користується цим. Для чого ти його використовуєш? Це у вашому стандарті? Чи використовуєте ви його, якщо цього не потрібно? Ви б використали його для нового проекту? Які ви бачите переваги?

На даний момент я все ще вживаю угорську з точно трьох причин , розумно уникаючи її для всього іншого:

1. Щоб відповідати існуючій кодовій базі при технічному обслуговуванні.
2. Для контролю, наприклад. "txtFirstName". Нам часто потрібно розрізняти (скажімо) значення "firstName" і "firstName" управління. Угорська надає зручний спосіб зробити це. Звичайно, я міг би набрати "firstNameTextBox", але "txtFirstName" так само легко зрозуміти і має менше символів. Більше того, за допомогою угорської мови засоби керування одного типу легко знайти, і вони часто групуються за назвою в IDE.
3. Коли дві змінні містять однакове значення, але відрізняються за типом. Наприклад, "strValue" для значення, фактично набраного користувачем, і "intValue" для того самого значення, як тільки воно було проаналізовано, як у цілому.

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

Оновлення:

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

Я не великий прихильник використання угорської нотації, але думаю так:

• Ми також можемо помітити, що швидше знайти рядок, що посилається на TextBox у вашому коді: ввівши "txt" у вікні пошуку.

Не уявляйте навпаки, де кожен елемент має своє ім’я. Вам може бути повільніше знаходити, куди ви хочете піти, правда?

Те ж саме стосується і DDL, коли ми хочемо звернутися до DropDownList, легше чи ні? :)

Люди не витратять стільки часу, щоб знайти, де цей елемент.

Використання префікса не підходить для сучасних компіляторів мов, таких як C #, але воно є корисним (для читання) для людей.

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

Системи угорської мови (теги для надмірного позначення оголошеного типу об'єкта) ніколи не виконували жодної мети, крім накладення поверхнево рівномірного вигляду на основі коду. Він був створений та розповсюджений нетехнічними менеджерами та недосвідченими програмістами, які неправильно зрозуміли наміри угорської програми Apps і вважали, що якість коду може бути покращена складними вказівками щодо кодування.

Обидва стилі виникли в Microsoft. У ці дні у конвенціях Microsoft про іменування категорично йдеться про "не використовувати угорські позначення".

Якщо ви знайдете правильну систему префіксів, ви можете поширити зношеність своїх клавіш, що зменшить витрати на заміну клавіатур.

Я думаю, що я міг би розширити це. Я використовував SH на своєму робочому місці протягом останніх, о, десять років або близько того (тому що це є в нашому Стандарті). Це ніколи не допомагало вирішити проблему.

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

В обох місцях я написав код протоколу, який вимагає примітивних типів фіксованого розміру. Це найвигідніший випадок використання, який я можу придумати для SH. Це не допомогло мені сказати, коли я пишу з SH, і не завадило мені, коли я написав без SH.

Отже, на закінчення, єдина різниця, яку я бачу, - це зношеність вашої клавіатури.

Я фактично почав використовувати SH в новому коді, який я написав цього місяця.

Моє завдання передбачало переписання деякого коду Perl в JS, щоб його можна було перемістити на клієнтську частину нашого веб-додатку. У Perl SH зазвичай не потрібні через сигіли ($ string, @array,% хеш).

У JavaScript я виявив, що SH є безцінним для відстеження типів структур даних. Наприклад,

var oRowData = aoTableData[iRow];

Це отримує об'єкт з масиву об'єктів за допомогою цілого індексу. Дотримання цієї конвенції дозволило мені досить довго шукати типи даних. Крім того, ви можете перевантажувати стислі імена змінних ( oRowпроти iRow).

tl; dr: SH може бути чудовим, якщо у вас складний код слабко набраною мовою. Але якщо ваш IDE може відстежувати типи, віддайте перевагу цьому.

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

Поняття "Угорська Угорщина" насправді було певним підходом, нерозумінням поняття "тип". Розробники систем сприйняли це буквально як тип компілятора (слово, байт, рядок, ...) на відміну від типу домену додатків (індекс рядків, індекс стовпців, ...).

Але я здогадуюсь, що кожен розробник проходить декілька фаз стилю, які в той час здаються чудовою ідеєю (а тип префіксації здається початківцю хорошою ідеєю), перш ніж потрапляти в підводні камені (змінюючи тип, створюючи нові, значущі префікси, тощо). Тож я думаю, що є інертність: від розробників, які не покращуються і розуміють, чому це поганий вибір, від розробників, що дотримуються стандартів кодування, які доручають практиці та людям, які використовують <windows.h>. Microsoft буде занадто дорогим для зміни, щоб позбутися позначень префікса (що в багатьох місцях є неправильним: WPARAM?).

Є одне, чого не вистачає людям з угорською. Угорська нотація насправді працює ВЕЛИКО з автозаповненням.

Скажімо, у вас є змінна, а ім'я - intHeightOfMonster.

Скажіть, ви забули ім’я змінної

Це може бути висотаOfMonster або MonsterHeight або MeasurementMonsterHeight

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

Знаючи, що heightOfMonster є цілим, ви просто набираєте i і voila.

Економити час.