резюме документа
"Угорське угоду" про імена ідентифікаторів Чарльза Симонії.
Примітка від dr. GUI
Ще за часів розробки перших версій DOS, доктор Чарльз Симонії представив угоду про імена ідентифікаторів, в якому для вказівки функціонального призначення об'єкта, представленого ідентифікатором використовується додавання префікса до імені ідентифікатора.
Угорська нотація є однією з методик, що дозволяють програмістам створювати більш читається код в короткі терміни. У більшій частині документації і файлів заголовків, виданих Microsoft за останні 15 років використовується Угорська нотація. Багато програмістів поза Microsoft прийняли дане угоди або іншу подібну схему формування імен ідентифікаторів.
Можливо найважливішою публікацією, яка пропагує Угорську нотацію була перша книга, читається майже кожним Windows - програмістом: "Windows programmin" Чарльза Петцольда. У книзі дана угода використовувалося для прикладів і приміток і було коротко описано в першому розділі.
Даний документ являє початковий варіант роботи Симонії.
Угода про ідентифікатори в програмі.
Даний документ призначений для викладу основних достоїнств про формальне формуванні ідентифікаторів.
При введенні нового ідентифікатора в програму, хороший програміст враховує такі фактори:
- мнемонічне значення. ідентифікатор повинен легко запам'ятовуватися
- смислове значення. роль ідентифікатора повинна бути ясна з його назви
- спадкоємність. часто розглядається як чисто естетична ідея, але все ж, схожі об'єкти повинні мати схожі ідентифікатори.
- швидкість рішення. придумування, введення і редагування ідентифікатора не повинні займати занадто багато часу, ідентифікатор не повинен бути занадто довгим.
Вибір імен може стати завданням, що поглинає зайвий час у розробника. Часто ідентифікатор, що задовольняє одним умовам суперечить іншим. Крім того, підтримати спадкоємність імен іноді буває досить важко.
переваги Угод
Дані угоди про ідентифікатори забезпечують зручну технологію для формування імен, які відповідають вищезазначеним критеріям. Основною ідеєю є передача основних характеристик ідентифікатора як частини в його назві. Ця проста ідея, безумовно, вимагає уточнення (що, наприклад, мається на увазі під "критерієм", що робити якщо вони (критерії) не унікальні?). Однак, давайте спочатку обговоримо загальні положення.
Назви будуть мнемонічними в строго певному сенсі: ідентифікатор буде очевидний для того, хто пам'ятає назву характеристики або принцип його побудови.
Назви мають смислове значення: повинна бути можливість відобразити будь-яку назву в наборі характеристик.
Назви будуть несуперечливі, так як зроблені тими ж самими правилами.
Побудова назв буде проводиться механічно, отже швидко.
Вирази в програмі можуть бути перевірені на спадкоємність методами, схожими на звичайні вимірювання властивостей об'єкта.
Правила позначення
Пропонуються наступні правила позначення: 1) Опис характеристики ідентифікатора входить в ідентифікатор. Зручною пунктуацією є вказівка характеристики перед назвою, з поділом їх (початком назви з великої літери в Сі, наприклад: rowFirst: row - характеристика, Fist - назва).
2) Назва відрізняють ідентифікатори, які мають один і той же тип і існуючі в одному контексті. Контекстом може бути як система в цілому, так і блок, процедура, структура даних в залежності від середовища програмування. Якщо існує стандартну назву, воно повинно бути використано. Вибір повинен бути максимально простим, так як потрібно унікальність ідентифікатора тільки в межах певного контексту.
3) Прості типи названі короткими тегами, які обрані програмістом. Такі теги повинні бути інтуїтивно зрозумілі більшості програмістів.
Тег повинен бути коротким для виконання четвертого умови (фактора), введеного нами вище. Назви складових типів повинні включати імена складових. Існують стандартні схеми побудови покажчика і масиву. Інші типи даних можуть бути визначені довільно. Наприклад префікс p використовується для покажчиків. В принципі, угоди можуть бути збагачені відповідно до нових схемами типів даних. Однак стандартні конструкції можуть послужити ще довгий час. Слід зазначити що поля структур не повинні брати участь у формуванні префікса, так як в цьому випадку конструкції більш ніж з двома полями були б просто не читаються. Більш важлива передача в префікс для структури її суті, залежною немає від набору полів, а від способу її використання.
Я рекомендую використання нового тега для кожної нової структури даних. Тег з деякою пунктуацією (перша або усі великі літери) теж може і повинен використовуватися як ім'я типу для структури. Використання нових тегів так само виправдано в тих випадках, коли це впливає на читабельність програми.
Мій досвід показує, що теги більш важкі для вибору в порівнянні з назвами. Коли необхідний новий тег, першим бажанням буває використовувати короткий, наочний, загальний і універсальний термін як ім'я типу. Це - майже завжди помилка. Не можна резервувати найбільш корисні терміни і фрази для приватних цілей конкретного завдання або навіть версії. Як правило будь-який універсальний термін однаково застосуємо до багатьох типів, навіть в тій же самій програмі.
Зверніть увагу, що, як правило, очевидний вибір для назви, є і найправильнішим. Причиною цього є те, що назва повинна бути унікальною в рамках значно меншого в порівнянні з тегом контексту. Так як назви, як правило, не беруть участі у формуванні інших назв, їм не потрібно бути особливо короткими.
Наприклад ми створюємо графічну програму. В даному випадку у нас існує тип даних "колір". Природним бажанням є зробити префікс color для позначення кольору. Однак при детальному розгляді може виявитися, що застосування терміна color більш зручно в додатку до назви, наприклад: LineColor. Для позначення кольору більш вигідним є скорочення, наприклад clr. clrDefault.
Позначення для спрощення написання.
Правильне формування ідентифікаторів має дозволити кільком програмістам незалежно створювати програму для вирішення одного завдання. Кожен програміст повинен знати правила іменування, інакше буде неможливо організувати взаємодію. Такий експеримент марний при розгляді великого проекту, проте вдає із себе чітку мету. Результатом є можливість розуміти і виправляти програму, написану іншою людиною. Такий результат можна досягти при належному використанні общеопределенних угод. Саме тому процес документування тегів вкрай важливий.
Позначення для процедур.
На жаль, просте поняття кваліфікованих надрукованих тегів не працює для назв процедури. Деякі процедури не отримують параметрів або не повертають значення. Контексти назв процедур мають тенденцію бути великими. Наступний набір спеціальних правил для процедур може працювати досить задовільно:
1) Назви процедур повинні відрізнятися від інших назв пунктуацією, наприклад, завжди починаючись з великої літери (тоді як теги характеристик інших ідентифікаторів пишуться малими літерами).
2) Починайте назву процедури з тега типу значення, що повертається, якщо таке існує.
3) Виразіть дію процедури в одному або двох словах. Слова повинні бути розділені пунктуацією для більш простого розбору читачем (звичайний метод полягає в використанні заголовних ініціалів для кожного слова).
4) У кінець назви можна додати список тегів деяких або всіх формальних параметрів, якщо є сенс.
Останній пункт суперечить більш раннім зауважень по опису структури даних. Якщо параметри процедури будуть змінені, то це спричинить за собою зміну імені та всіх точок виклику процедури. Однак така зміна може бути використано для перевірки того, що всі крапки виклику зміненої процедури будуть також виконані коректно. У випадку ж із структурами даних, додавання або зміна поля не робить вирішального впливу на використання типу даних. У разі якщо процедура має один або два параметри використання тегів спростить вибір імені.
Таблиця 1. Деякі приклади для назв процедури