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

Причини використання угоди про іменування (на відміну від дозволу програмістам вибирати будь-яку послідовність символів) включають наступне:

Щоб зменшити зусилля, необхідні для читання та розуміння початкового коду;Derek M. Jones «Operand names influence operator precedence decisions» An experiment investigating the effect of variable names on operator precedence selection Щоб перевірки коду зосередилися на питаннях, важливіших за синтаксис і стандарти імен. Щоб інструменти перевірки якості коду зосереджували свої звіти на важливих питаннях, крім синтаксису та стилю.

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

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

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

Читабельність Добре підібрані ідентифікатори значно полегшують розробникам і аналітикам розуміння того, що робить система та як виправити або розширити вихідний код для застосування для нових потреб. Наприклад, хоча a = b * c;синтаксично правильний, його мета неочевидна. Порівняйте це з: weekly_pay = hours_worked * hourly_pay_rate;що визначає значення і зміст початкового коду, принаймні для тих, хто знайомий з контекстом виразу.

Експерименти показують, що стиль ідентифікатора впливає на запам'ятовування та точність, а знайомство зі стилем прискорює запам'ятовування.

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

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

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

Деякі міркування: коротші ідентифікатори можуть бути кращими як більш доцільні, оскільки їх легше вводити (хоча багато IDE та текстові редактори забезпечують завершення тексту, що пом'якшує це) надзвичайно короткі ідентифікатори (такі як «i» або «j») дуже важко однозначно розрізнити за допомогою автоматизованих інструментів пошуку та заміни (хоча це не проблема для інструментів на основі регулярних виразів) довші ідентифікатори можуть бути кращими, оскільки короткі ідентифікатори не можуть кодувати достатньо інформації або виглядають надто загадковими довші ідентифікатори можуть бути неприйнятними через візуальний безлад

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

Стислість у програмуванні частково пояснюється: ранні компонувальники, які вимагали обмеження імен змінних 6 символами для економії пам'яті. Пізніший «прогрес» дозволив використовувати довші імена змінних для розуміння людиною, але лише перші кілька символів були значущими. У деяких версіях BASIC, таких як TRS-80 Level 2 Basic, дозволялися довгі імена, але лише перші дві літери були значущими. Ця функція дозволяла помилкову поведінку, яку було важко налагодити, наприклад, коли використовувалися такі імена, як «VALUE» і «VAT», які мали бути різними. ранні редактори вихідного коду не мають автозаповнення ранні монітори з низькою роздільною здатністю з обмеженою довжиною рядка (наприклад, лише 80 символів) велика частина інформатики походить від математики, де імена змінних традиційно складаються лише з однієї літери

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

Багатослівні ідентифікатори Загальна рекомендація: «Використовуйте значущі ідентифікатори». Одне слово може бути не таким значущим або конкретним, як кілька слів. Отже, деякі домовленості про найменування визначають правила обробки «складених» ідентифікаторів, що містять більше одного слова.

Оскільки більшість мов програмування не дозволяють використовувати пробіли в ідентифікаторах, необхідний метод розмежування кожного слова (щоб полегшити наступним читачам інтерпретацію того, які символи належать якому слову). Історично деякі ранні мови, зокрема FORTRAN (1955) і ALGOL (1958), дозволяли пропуски в ідентифікаторах, визначаючи кінець ідентифікаторів за контекстом. Від цього відмовилися в пізніших мовах через складність токенізації. Можна писати назви, просто з'єднуючи слова, і це іноді використовується, як у mypackage для назв пакетів Java,Naming a Package хоча розбірливість страждає для більш довгих термінів, тому зазвичай використовується певна форма розділення.

Слова розділені роздільником Один із підходів полягає в тому, щоб розділяти окремі слова не буквено-цифровим символом. Для цієї мети зазвичай використовуються два символи: дефіс («-») і підкреслення («_»); наприклад, назва з двох слів «два слова» буде представлена як «два слова» або «два_слова». Дефіс використовується майже всіма програмістами, які пишуть COBOL (1959), Forth (1970) і Lisp (1958); він також поширений в Unix для команд і пакетів і використовується в CSS. Ця конвенція не має стандартної назви, хоча її можна називати lisp-case або COBOL-CASE (порівняйте Pascal case), kebab-case, brochette-case або інші варіанти. UnderscoreVersusCapitalAndLowerCaseVariableNaming З них kebab-case, датований принаймні 2012 роком, з тих пір набув певної популярності.Living Clojure (2015), by Carin Meier, p. 91lodash: kebabCase

Навпаки, мови традиції FORTRAN/ALGOL, зокрема мови сімейств C і Pascal, використовували дефіс для інфіксного оператора віднімання та не бажали вимагати пробілів навколо нього (як мови вільної форми), запобігаючи його використанню в ідентифікатори. Альтернативою є використання підкреслень; це поширене явище в сімействі C (включаючи Python), зі словами з малого регістру, які можна знайти, наприклад, у «Мові програмування C» (1978), і стало відомим як «зміїний регістр». Знаки підкреслення у верхньому регістрі, як у UPPER_CASE, зазвичай використовуються для макросів препроцесора C, тому відомих як MACRO_CASE, і для змінних середовища в Unix, таких як BASH_VERSION у bash. Іноді це з гумором називають SCREAMING_SNAKE_CASE.

Слова, розділені регістром Інший підхід полягає в тому, щоб позначити межі слів за допомогою середньої літери, що називається «camelCase», «PascalCase» і багатьма іншими іменами, таким чином відповідно відображаючи «два слова» як «twoWords» або «TwoWords». Ця конвенція зазвичай використовується в Pascal, Java, C# та Visual Basic . Обробка ініціалізмів в ідентифікаторах (наприклад, «XML» і «HTTP» у XMLHttpRequest) різниться. Деякі вимагають, щоб вони були написані у нижньому регістрі (наприклад, XmlHttpRequest), щоб полегшити введення, читабельність і легкість сегментації, тоді як інші залишають їх у верхньому регістрі (наприклад, XMLHTTPRequest). для точності.

Приклади форматів багатослівних ідентифікаторів +Формати багатослівних ідентифікаторівФорматуванняІменадва словаflatcaseДВА СЛОВАВЕЛИКИЙ РЕГІСТРдва слова(нижній) camelCase, dromedaryCaseДва словаPascalCase, UpperCamelCase, StudlyCaseдва_словаsnake_case, snail_case, вибоїна_caseДВА_СЛОВАALL_CAPS, SREAMING SNAKE CASE, MACRO_CASE, CONSTANT_CASEдва_словаcamel_Snake_CaseДва_словаPascal_Snake_Case, Title_Caseдва словаkebab-case, dash-case, lisp-case, spinal-caseДВА СЛОВАTRAIN-CASE, COBOL-CASE, SCREAMING-KEBAB-CASEДва словаTrain-Case, HTTP-Header-Case

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

Угорська нотація Мабуть, найвідомішою є угорська нотація, яка кодує призначення («Apps Hungarian») або тип («Systems Hungarian») змінної в назві. Наприклад, префікс «sz» для змінної szName вказує на те, що змінна є рядком із нульовим завершенням.

Позиційна нотація Стиль, який використовується для дуже короткого (вісім символів і менше), може бути таким: LCCIIL01, де LC буде заявкою (акредитиви), C для COBOL, IIL для конкретної підмножини процесу, а 01 — порядковий номер.

Цей вид конвенції все ще активно використовується в мейнфреймах, що залежать від JCL, і також спостерігається у стилі MS-DOS 8.3 (максимум вісім символів із крапкою-роздільником, після якого йде три символи).

Складена схема слів (OF Language) «Мова OF» IBM була задокументована в посібнику IMS (система управління інформацією).

У ньому детально описана схема слів PRIME-MODIFIER-CLASS, яка складалася з імен на кшталт «CUST-ACT-NO» для позначення «номера рахунку клієнта».

Слова PRIME мали на меті позначити основні «сутності», що представляють інтерес для системи.

Для додаткового уточнення, кваліфікації та читабельності використано слова-МОДИФІКАТОРИ.

Слова CLASS в ідеалі були б дуже коротким списком типів даних, що стосуються конкретної програми. Загальні слова CLASS можуть бути такими: NO (номер), ID (ідентифікатор), TXT (текст), AMT (сума), QTY (кількість), FL (прапор), CD (код), W (робота) тощо. На практиці доступні слова КЛАСУ являтимуть собою список із менш ніж двох десятків термінів.

Слова CLASS, зазвичай розташовані праворуч (суфікс), служили майже тій самій меті, що й префікси угорської нотації.

Призначення слів CLASS, крім узгодженості, полягало в тому, щоб вказати програмісту тип даних певного поля даних. До прийняття полів BOOLEAN (лише два значення) FL (прапор) вказував на поле лише з двома можливими значеннями.

Спеціальні мовні умовності

ActionScript