Угорська нотація
Угорська нотація - угода про іменування змінних, констант а так же ідентифікаторів в коді програм.
Відмінності Системної Угорської та Угорської для Додатків
У Угорської для Додатків були визначені конкретні приставки, такі як "ix" для позначення індексу в масиві, "c" для лічильників, "d" для різниці між двома числами (наприклад, "dx" означав "ширину"), і т.д . Системна Угорська мала набагато менш корисні приставки, такі як "l" для довгого цілого (long), "ul" для беззнакового довгого цілого (unsigned long), і "dw" для подвійного слова (double word). яке, фактично, є беззнаковим довгим цілим і т.д. У Системної Угорської єдиною річчю, про яку говорив вам префікс, фактично був лише тип змінної. Тобто ми бачимо що відмінність принципова хоча ідея додавання додаткової інформації про змінну за допомогою системи префіксів одна і та ж.
Багато програмістів поза Microsoft прийняли дане угоди або іншу подібну схему формування імен ідентифікаторів. Можливо, одним з вирішальних факторів пропагує Угорську нотацію була книга, яку читав майже кожен цікавиться програміст Windows: "Windows programmin" Чарльза Петцольда. У книзі дана угода використовувалося для прикладів і приміток і було коротко описано в першому розділі. Суть Угорської нотації зводиться до того, що імена ідентифікаторів предваряются заздалегідь обумовленими префіксами, що складаються з одного або декількох символів. При цьому, як правило, ні сама наявність префіксів, ні їх написання не є вимогою мов програмування.
Наведу коротку таблицю префіксів Угорської нотації (Системної).
Звичайно у кожного програміста (або колективу програмістів) можуть бути своїми, але сенс вигадувати велосипед немає, розумніше звичайно просто частково модифікувати набір правил під свої потреби і завдання залишивши основну безліч трохи ізмннимі.
У більш широкому розумінні, Угорську нотацію можна застосовувати навіть в мовах в яких немає типів змінних, наприклад при роботі з даними з помощю префіксів можна розрізняти, скажімо змінні містять внутрішні, перевірені дані і дані введені користувачем або з інших зовнішніх, щодо вашої системи (програми ), що дозволить уникнути критичних ощібок і зробити програму менш вразливою в сенсі безпеки.
Приклад.
Змінні є зовнішніми матимуть префікс us (UnSafe небезпечно) тоді скажемо матимемо назви пременися:
UserName - ім'я користувача (дані нашої системи);
UserInfo - інформація про користувача (дані нашої системи);
usUserName - ім'я користувача (отримані дані);
usUserInfo - інформація про користувача (отримані дані);
Незважаючи на широку поширеність Угорської нотації, є програмісти які її вважають не тільки марною а й шкідливою, що заважає і заплутується. У потверждение своєї думки наводять такі аргументи:
1) Будь-яка зайва інформація збиває користувача з пантелику;
2) Проблеми изменеия назв змінних при зміні їх типу;
3) Відсутність контролю;
4) Витрата часу тому є підсвічування синтаксису;
5) Заява Microsoft про те що «Угорська Нотація не рекомендується;
6) «Вписування типу змінної в її ім'я (так звана угорська нотація) неповноцінне - компілятор і так знає типи і може перевірити їх. »(За деякими даними слова Лінус Торвальдса, супротивника Угорської нотації);
1) справа звички, якщо я читаю "сенс" програми я просто не дивлюся на префікси, якщо мені необхідно знати тип або перевірити коректність типів я дивлюся префікс;
2) якщо необхідно змінити тип змінної, то це явно помилка допущена при проетірованіі і в таких випадках код переписується, по-друге я скажу що це притягнутий одиничний випадок (хлопці мають на увазі зміна типу int на long або інший цілочисельний тип і тоді потрібно буде змінити назву змінної скажімо з iSize на lSize) а що ви будете робити якщо тип змінної з long зміниться на double? Вам дуже допоможе то що змінна називалася Size а не lSize? а що ви не будете виправляти всі порівняння змінної? арифметичні операції? змінювати типи змінних використовуваних для зберігання результатів обчислень з використанням цієї змінної?
наприклад в коді є такий шматок
long lRes;
lRes = lSize -1;
if (lRes> 0)
3) Угорська нотація якщо і призначена для контролю то тільки з боку програміста;
розглянемо приклад із записом без використання нотації
ніби все ОК, компілятор не лається і тільки писав колись знав що змінна Param1 типу DWORD
зовсім інша реакція буде якщо ви користуєтеся нотацією і побачите код
int iRes;
iRes = (int) dwParam1;
ви скажете як же так змінної типу int присвоюється значення типу DWORD можуть втрати дані? і вже приділіть увагу коду і можливо виправиться не тривіальну помилку, яка може виникати досить рідко і через це її знайти і виявити в складній системі досить проблематично.
4) підсвічування синтаксису це просто чудово, але є кілька АЛЕ і купка ЯКЩО;
сам дуже люблю такі речі, але вибачте і розкажіть де скажімо в Microsoft Visual Studio налаштувати підсвічування для bool, int, long і т.д. кольори підсвічування? а де це налаштувати в стандартному "блокноті" тому що скажімо у мене немає студії і я використовую "блокнот" і командний рядок для компіляції? А якщо я сідаю за чужий комп'ютер з абсолютно по іншому налаштованої підсвічуванням синтаксису? А якщо я дальтонік і для мене 30% квітів (відтінків) виглядають абсолютно однаковими? А якщо я розбираю код скажімо в книжці або на сторінці сайту де немає коштів для підсвічування? і т.д. і т.д.
5) у Microsoft на те з'явилися вагомі причини після введення нових технологій в програмування зокрема "керованого коду" при використанні яких, якщо придерживатся нотації дійсно можна путатся і заплутати інших якщо використовувати нотацію всюди;
6) відношу швидше до вираження вирвана з контексту (хоча все може бути.);
І так. для себе я бачу одні плюси і маленький мінус в тому що все таки ці 1-5 символів префікса треба набирати. Людей які не використовують (навмисне, не будучи противниками) Угорську нотацію жорстоко дорікати теж не став хоча думка про те що вони відносяться до егоїстів мене не покидає :) Кожному самому вирішувати що використовувати а що ні, але не забувайте що останнім часом написати що щось вартісне самому дуже важко і довго, і вам рано чи пізно доведеться працювати в колективі у якого є свої домовленості і їх доведеться дотримуватися, звичайно якщо ви займаєтеся програмуванням професійно, а не заради проведення часу.