Яка користь від використання угорських позначень?

Однією з речей, з якими я борюся, є не використання угорських позначень. Мені не хочеться переходити до визначення змінної, щоб побачити, що це за тип. Коли проект розгортається, приємно мати можливість переглядати змінну з префіксом 'bool' і знати, що він шукає true / false замість значення 0/1 .

Я також багато працюю в SQL Server. Я префіксую свої збережені процедури з 'sp', а мої таблиці з 'tbl', не кажучи вже про всі мої змінні відповідно до бази даних.

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

Оскільки його первісний намір (див. Http://www.joelonsoftware.com/articles/Wrong.html та http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids ) було неправильно зрозумілим, і це було ( ab) використовується для того, щоб допомогти людям запам'ятати тип типу змінної, коли мова, яку вони використовують, статично не набрана. У будь-якій мові, яка не є статично введеною, вам не потрібен доданий баласт префіксів, щоб повідомити про тип типу змінної. У багатьох нетипізованих мовах скриптів це може допомогти, але його часто зловживають до того, що стає зовсім громіздким. На жаль, замість того, щоб повернутися до початкового наміру угорської нотації, люди щойно перетворили її на одну з тих "злих" речей, яких слід уникати.

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

оновлення (у відповідь на коментар delnan)

ІМХО слід уникати зловживаної версії, як чуми, оскільки:

• це ускладнює називання. Коли (ab) використання угорських позначень завжди будуть дискусії щодо того, наскільки специфічними повинні бути префікси. Наприклад: listboxXYZабо MyParticularFlavourListBoxXYZ.
• це робить імена змінних довшими, не сприяючи розумінню того, для чого ця змінна.
• він начебто перемагає об'єкт вправи, коли для уникнення довгих префіксів вони скорочуються до абревіатур, і вам потрібен словник, щоб знати, що означає кожна абревіатура. Чи uiє безпідписане ціле число? інтерференційний підрахунок інтерфейсу? щось робити з інтерфейсами користувача? І це може затягнутися довго . Я бачив префікси понад 15, здавалося б, випадкових символів, які повинні передавати точний тип вару, але насправді лише містифікувати.
• вона швидко застаріла. Коли ви змінюєте тип змінної люди незмінно (lol), забудьте оновити префікс, щоб відобразити зміну, або навмисно не оновлюйте його, оскільки це призведе до зміни коду скрізь, де використовується var ...
• це ускладнює розмову про код, оскільки як "@g". сказано: Імена змінних з угорською нотацією, як правило, важко вимовляють суп з алфавітом. Це гальмує читабельність та обговорення коду, оскільки ви не можете «сказати» жодне з імен.
• ... ще багато чого, що я не можу згадати на даний момент. Можливо, тому, що мені було приємно довго не стикатися з зловживаними угорськими позначеннями ...

Угорська нотація - це найменування анти-зразка в сучасних середовищах програмування та форми тавтології .

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

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

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

Вигода НЕ використовуючи Угорська нотація в основному тільки уникнення його недоліків:

• Угорська нотація є зайвою, коли перевірку типу здійснює компілятор. Компілятори для мов, що забезпечують перевірку типу, гарантують, що використання змінної автоматично відповідає її типу; перевірки очей є зайвими і піддаються людській помилці.

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

• Угорська нотація стає заплутаною, коли вона використовується для представлення декількох властивостей, як у a_crszkvc30LastNameCol: постійному довідковому аргументі, що містить вміст стовпця бази даних LastNameтипу, varchar(30)який є частиною первинного ключа таблиці.

• Це може призвести до невідповідності, коли код змінено або переноситься. Якщо тип змінної змінено, то або прикраса назви змінної буде невідповідно новому типу, або ім'я змінної має бути змінено. Особливо відомим прикладом є стандартний WPARAMтип та супровідний wParamформальний параметр у багатьох деклараціях системної системи Windows. 'W' означає 'word', де 'word' є початковим розміром слова апаратної архітектури платформи. Спочатку це був 16-бітний тип 16-розрядних архітектур слів, але був змінений на 32-розрядний у 32-розрядних архітектурах слів, або 64-бітний тип на 64-бітових архітектурах слів у пізніших версіях операційної системи, зберігаючи його оригінальна назва (її справжній базовий тип - це)UINT_PTR, тобто непідписане ціле число, достатньо велике, щоб вмістити покажчик). Семантичний опір, а значить, плутанина та непослідовність програміста від платформи до платформи, припускають, що 'w' означає 16-бітове в тих різних середовищах.

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

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

• Це робить код менш читабельним, обробляючи призначення змінної непотрібним типом та визначаючи префікси.

• Додаткова інформація про тип може недостатньо замінити більш описові назви. Наприклад sDatabase, не говорить читачеві, що це таке. databaseNameможе бути більш описовою назвою.

• Коли назви достатньо описові, додаткова інформація про тип може бути зайвою. Наприклад, firstNameце, швидше за все, рядок. Тож його іменування sFirstNameлише додає безладу коду.

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

Як специфічна проблема MS SQL Server:

Будь-які збережені процедури з префіксом 'sp_' спочатку шукаються в базі даних Master, а не в тій, в якій вона створена. Це призведе до затримки виконання збереженої процедури.

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

За іронією долі, з особистого досвіду головний сценарій, який я бачив угорською, - це або "культово-культове" програмування (тобто інший код використовує його, тож давайте продовжувати використовувати його лише тому, що) або у VB.NET, щоб вирішити те, що мова є нечутливі до регістру (наприклад, Person oPerson = new Personтому, що ви не можете використовувати Person person = new Personі Person p = new Personзанадто розпливчасті); Я також бачив префіксацію "the" або "my" замість цього (як у Person thePerson = new Personчи більш брудний Person myPerson = new Person), в цьому конкретному випадку.

Я додаю лише те, що коли я використовую угорський, як правило, для управління ASP.NET, і це справді питання вибору. Я вважаю, що це дуже некрасиво набирати TextBoxCustomerNameабо CustomerNameTextBoxпроти більш простого txtCustomerName, але навіть це відчувається "брудно". Я вважаю, що для управління слід використовувати якусь угоду про іменування, оскільки може бути декілька елементів керування, які відображають однакові дані.

Я просто зосередитимуся на SQL Server відтоді, як ви це згадали. Я не бачу причин ставити 'tbl' перед столом. Ви можете просто подивитися будь-який код tSQL і виділити таблицю за способом її використання. Ви ніколи Select from stored_procedure.або не Select from table(with_param)хотіли б, щоб ви використовували UDF або Execute tblTableOrViewNameлюбите збережену процедуру.

Таблиці можна переплутати з видом, але якщо мова йде про те, як вони використовуються; різниці немає, тож у чому справа? Угорська нотація може заощадити час на пошук у SSMS (під таблицею чи переглядами?), Але це стосується цього.

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

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

Ще одна річ, яку слід додати, це те, які абревіатури ви б використовували для цілого фреймворку, такого як .NET? Так, запам'ятати так просто, що btnпредставляє собою кнопку і txtявляє собою текстове поле. Однак що ви маєте на увазі для чогось подібного StringBuilder? strbld? Про що CompositeWebControl? Ви використовуєте щось подібне:

CompositeWebControl comWCMyControl = new CompositeWebControl();

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

На мій погляд на речі, угорська нотація - це хитрість обійти недостатньо потужну систему типу. У мовах, які дозволяють визначити власні типи, відносно тривіально створити новий тип, який кодує поведінку, яку ви очікуєте. У розголосі Джоела Спольського на угорській нотації він наводить приклад використання його для виявлення можливих атак XSS, вказуючи, що змінна або функція або небезпечна (для нас), або безпечна (и), але вона все ще покладається на програміста для візуальної перевірки. Якщо натомість у вас є система розширюваного типу, ви можете просто створити два нові типи, UnsafeString та SafeString, а потім використовувати їх за потребою. Як бонус, тип кодування стає:

SafeString encode(UnsafeString)

і відсутність доступу до внутрішніх даних UnsafeString або використання інших функцій перетворення стає єдиним способом пройти шлях від UnsafeString до SafeString. Якщо всі ваші вихідні функції мають лише екземпляри SafeString, неможливо вивести необрізну рядок [заборона шенганіган з перетвореннями, такими як StringToSafeString (someUnsafeString.ToString ())].

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

Мовою, такою як C, звичайно, ви накрутили, що int є int - це int, і ви не можете багато з цим зробити. Ви завжди можете грати в ігри зі структурами, але це суперечка, вдосконалення це чи ні.

Що стосується іншої інтерпретації угорської нотації, то префіксація IE до типу змінної, це просто нерозумно і заохочує ледачі практики, такі як іменування змінних uivxwFoo замість чогось значущого, як countOfPeople.

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

У динамічно набраних мовах це може іноді допомогти, але для мене це відчувається однозначно. Ви вже відмовились від обмеження своїх функцій точними доменами / кодоменами; якщо всі ваші змінні названі угорською нотацією, ви просто відтворюєте те, що дала б вам система типів. Як ви виражаєте поліморфну ​​змінну, яка може бути цілим чи рядком в угорському позначенні? "IntStringX"? "IntOrStringX"? Єдине місце, де я коли-небудь використовував угорські позначення, був у складальному коді, тому що я намагався повернути те, що отримав, якби мав типову систему, і це було перше, що я коли-небудь кодував.

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

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

Я бачу три "помилки" у вашому баченні: 

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

2 / Типи можуть змінюватися протягом циклу розвитку. 32-розрядне ціле число може стати 64-бітним цілим числом в якийсь момент з поважних причин, які не були виявлені на початку проекту. Отже, перейменування intX в longX або залишення його ім'ям, яке вказує на неправильний тип, є поганою кармою. 

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

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

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

Це ... в значній мірі причина, чому багато робочих місць вигадують це, я думаю.

Вона виникла на мовах , які необхідні його.
За часів глобальних змінних бонанса . (за браком альтернатив)
Це нам добре послужило.

Єдине реальне використання у нас є для цього сьогодні є Джоел Спольскі один .
Відстежувати окремі атрибути змінної, як-от її безпека .

( наприклад, "Чи safeFoobarмає змінна має зелене світло для введення в SQL-запит?
- Як це називається safe, так")

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

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

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

Причина цього уникається через систему угорських, яка порушує DRY (префікс - саме той тип, який може отримати компілятор і (хороший) IDE)

програми угорських префіксів OTOH з використанням змінної (тобто scrxMouse - координатна ось на екрані, це може бути внутрішній, короткий, довгий або навіть нестандартний тип (typedefs дозволить вам легко змінити))

нерозуміння систем - це те, що знищило Угорщину як найкращу практику

Скажімо, у нас є такий метод (у C #):

int GetCustomerCount()
{
    // some code
}

Тепер у коді ми називаємо це так:

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

ІНТ не говорить нам дуже багато. Сам факт, що щось є інтом, не говорить нам про те, що в ньому є. Тепер припустимо, натомість ми називаємо це так:

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

Тепер ми можемо побачити, яка мета змінної. Було б важливо, якщо ми знаємо, що це int?

Первісна мета угорської мови, однак, була змусити вас зробити щось подібне:

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

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

Угорський мав певні цілі в VB раніше, ніж Option Strict Onіснував, тому що в VB6 і до (і в VB .NET з Option Strict Off) VB примушував би типи, тож ви можете зробити це:

Dim someText As String = "5"
customerCount = customerCount + someText

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

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

У .NET, при статичному введенні, це не потрібно. І угорська занадто часто використовувалася як заміна хорошого іменування. Забудьте про угорську мову та виберіть замість неї хороші імена.

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

У колишні часи, коли все, що у вас було, було струнним, int, bool та float, символів sibf було б достатньо. Але з рядком + коротким, проблеми починаються. Використовувати ціле ім'я для префікса чи str_name для рядка? (Хоча імена майже завжди є рядками - чи не так?) Що з класом Street? Імена стають все довше і довше, і навіть якщо ви використовуєте CamelCase, важко сказати, де закінчується префікс типу і де починається назва змінної.

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

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

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

Це жахливо, і якщо ти зробиш це, отже, матимеш

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

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

Якщо у вас багато змінних, вони зазвичай групуються в браузері об'єктів, який є частиною вашої IDE. Тепер, якщо 40% починаються з i_ для int, а 40% з s_ для рядка, і вони сортуються за алфавітом, важко знайти значну частину імені.

Єдине місце, де я все ще регулярно вживаю або угорські, або аналогічні суфікси, - це в контекстах, де однакові семантичні дані присутні у двох різних формах, як перетворення даних. Це може бути у випадках, коли є кілька одиниць вимірювання, або коли є кілька форм (наприклад, рядок "123" і ціле число 123).

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

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

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

Ідея про те, що угорщина накладає значне навантаження на технічне обслуговування, коли зміна типів змінних є дурною - як часто ви змінюєте змінні типи? Крім того, перейменування змінних легко:

Просто використовуйте IDE для перейменування всіх випадків. -Гендер, відповідаючи Гусь

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