Узгодження імен

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

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

  • Щоб зменшити зусилля, необхідні для читання та розуміння початкового коду;[1]
  • Щоб перевірки коду зосередилися на питаннях, важливіших за синтаксис і стандарти імен.
  • Щоб інструменти перевірки якості коду зосереджували свої звіти на важливих питаннях, крім синтаксису та стилю.

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

Потенційні переваги[ред. | ред. код]

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

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

Виклики[ред. | ред. код]

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

Читабельність[ред. | ред. код]

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

Наприклад, хоча

 a = b * c;

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

 weekly_pay = hours_worked * hourly_pay_rate;

що визначає значення і зміст початкового коду, принаймні для тих, хто знайомий з контекстом виразу.

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

Загальні елементи[ред. | ред. код]

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

Довжина ідентифікаторів[ред. | ред. код]

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

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

Деякі міркування:

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

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

Стислість у програмуванні частково пояснюється:

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

Літера і цифри[ред. | ред. код]

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

Багатослівні ідентифікатори[ред. | ред. код]

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

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

Слова розділені роздільником[ред. | ред. код]

Один із підходів полягає в тому, щоб розділяти окремі слова не буквено-цифровим символом. Для цієї мети зазвичай використовуються два символи: дефіс («-») і підкреслення («_»); наприклад, назва з двох слів «два слова» буде представлена як «два слова» або «два_слова». Дефіс використовується майже всіма програмістами, які пишуть COBOL (1959), Forth (1970) і Lisp (1958); він також поширений в Unix для команд і пакетів і використовується в CSS.[5] Ця конвенція не має стандартної назви, хоча її можна називати lisp-case або COBOL-CASE (порівняйте Pascal case), kebab-case, brochette-case або інші варіанти.[6][7][8][9] З них kebab-case, датований принаймні 2012 роком,[10] з тих пір набув певної популярності.[11][12]

Навпаки, мови традиції 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[13][14]
ДВА СЛОВА ВЕЛИКИЙ РЕГІСТР[13]
два слова (нижній) camelCase, dromedaryCase
Два слова PascalCase, UpperCamelCase, StudlyCase[15]
два_слова 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,[13] HTTP-Header-Case[16]

Метадані та гібридні конвенції[ред. | ред. код]

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

Угорська нотація[ред. | ред. код]

Мабуть, найвідомішою є угорська нотація, яка кодує призначення («Apps Hungarian») або тип («Systems Hungarian») змінної в назві.[17] Наприклад, префікс «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[ред. | ред. код]

Конвенції та передові методи кодування Adobe пропонують стандарти імен для ActionScript, які здебільшого відповідають стандартам ECMAScript. Стиль ідентифікаторів схожий на стиль Java.

Ада[ред. | ред. код]

В Ada єдиним рекомендованим стилем ідентифікаторів є Mixed_Case_With_Underscores.[18]

APL[ред. | ред. код]

In APL dialects, the delta (Δ) is used between words, e.g. PERFΔSQUARE (no lowercase traditionally existed in older APL versions). If the name used underscored letters, then the delta underbar (⍙) would be used instead.

C і C++[ред. | ред. код]

У C і C++ ключові слова та стандартні ідентифікатори бібліотек здебільшого написані малими літерами. У стандартній бібліотеці C найпоширенішими є скорочені назви (наприклад, isalnum для функції, яка перевіряє, чи є символ буквено-цифровим), тоді як стандартна бібліотека C++ часто використовує підкреслення як роздільник слів (наприклад, out_of_range). Ідентифікатори, що представляють макроси, за домовленістю записуються лише з використанням великих літер і підкреслення (це пов'язано з угодою багатьох мов програмування про використання ідентифікаторів у верхньому регістрі для констант). Імена, які містять подвійне підкреслення або починаються з підкреслення та великої літери, зарезервовані для реалізації (компілятор, стандартна бібліотека) і не повинні використовуватися (наприклад, __reserved або _Reserved).[19][20] Зовні це схоже на стропінг, але семантика відрізняється: підкреслення є частиною значення ідентифікатора, а не символами лапок (як стропінг): значенням __foo є __foo (що зарезервовано), а не foo (але в іншому просторі імен).

C#[ред. | ред. код]

Угоди про найменування C# зазвичай відповідають інструкціям, опублікованим Microsoft для всіх мов .NET[21] (див. розділ .NET нижче), але жодні угоди не застосовуються C# компілятор.

Інструкції Microsoft щодо іменування полів стосуються лише static, public і protected полів; поля, які не є static та мають інші рівні доступності (наприклад, internal та private), явно не охоплюються цими рекомендаціями.[22] Найбільш поширеною практикою є використання PascalCase для назв усіх полів, за винятком тих, які є private (і не є ані const, ані static), яким надаються імена, що використовують camelCase, перед яким стоїть одне підкреслення; наприклад, _totalCount .

Будь-яке ім'я ідентифікатора може мати префікс комерційного символу (@) без будь-яких змін у значенні. Тобто і factor, і @factor посилаються на той самий об'єкт. За домовленістю цей префікс використовується лише у випадках, коли інакше ідентифікатор був би або зарезервованим ключовим словом (наприклад, for і while), яке не можна використовувати як ідентифікатор без префікса, або контекстним ключовим словом (наприклад, from і where), у яких випадках префікс не є обов'язковим (принаймні, не під час його оголошення; наприклад, хоча оголошення dynamic dynamic; є дійсним, це зазвичай розглядатиметься як dynamic @dynamic; щоб одразу вказати читачеві, що остання є назвою змінної).

Dart/Flatter[ред. | ред. код]

У мові Dart, яка використовується у Flutter SDK, угоди подібні до умов Java, за винятком того, що константи записуються в нижньому регістрі. Dart нав'язує синтаксичне правило, згідно з яким нелокальні ідентифікатори, які починаються з підкреслення (_), розглядаються як приватні (оскільки мова не має явних ключових слів для публічного чи приватного доступу). Крім того, імена вихідних файлів не відповідають правилу Java «один загальнодоступний клас на вихідний файл, ім'я має збігатися», замість цього для імен файлів використовується snake_case.[23]

Go[ред. | ред. код]

У Go для написання багатослівних імен прийнято використовувати MixedCaps або mixedCaps, а не підкреслення. Коли йдеться про структури чи функції, перша буква вказує на видимість зовнішніх пакетів. Зробивши першу літеру великою, цей фрагмент коду експортується, тоді як нижній регістр робить його придатним для використання лише в поточній області.[24]

Java[ред. | ред. код]

У Java різні спільноти Java, такі як Sun Microsystems,[25] Netscape,[26] AmbySoft,[27] тощо. Нижче наведено зразок умов іменування, встановлених Sun Microsystems, де ім'я в «CamelCase» складається з ряду слів, з'єднаних без пробілів, причому початкова літера кожного слова, за винятком першого слова, написана великими літерами — наприклад, «camelCase».

Тип ідентифікатора Правила найменування Приклади
Класи Назви класів мають бути іменниками UpperCamelCase, з великою першою літерою кожного слова. Використовуйте цілі слова — уникайте акронімів і абревіатур (окрім випадків, коли абревіатура використовується набагато ширше, ніж довга форма, наприклад URL-адреса або HTML).
  • клас Raster {}
  • клас ImageSprite {}
Методи Методи мають бути дієсловами lowerCamelCase або багатослівними назвами, які починаються з дієслова малими літерами; тобто з першою літерою малої та першими літерами наступних слів великими.
  • run();
  • runFast();
  • getBackground();
Змінні Локальні змінні, змінні екземпляра та змінні класу також записуються в lowerCamelCase. Імена змінних не повинні починатися з символів підкреслення (_) або знака долара ($), навіть якщо обидва дозволені. Це відрізняється від інших конвенцій кодування, які стверджують, що підкреслення слід використовувати для префікса всіх змінних екземпляра.

Імена змінних мають бути короткими, але змістовними. Вибір назви змінної має бути мнемонічним — тобто таким, щоб вказувати випадковому спостерігачеві намір її використання. Слід уникати односимвольних імен змінних, за винятком тимчасових змінних, які «викидаються». Загальні назви для тимчасових змінних: i, j, k, m і n для цілих чисел; c, d і e для символів.

  • int i;
  • char c;
  • float myWidth;
Константи Константи слід писати великими літерами, розділеними символами підкреслення. Імена констант також можуть містити цифри, якщо це необхідно, але не як перший символ.
  • static final int MAX_PARTICIPANTS = 10;

Компілятори Java не дотримуються цих правил, але недотримання їх може призвести до плутанини та помилкового коду. Наприклад, widget.expand() і Widget.expand() увазі істотно різні поведінки: widget.expand() передбачає виклик методу expand() в екземплярі під назвою widget, тоді як Widget.expand() передбачає виклик статичного методу expand() у класі Widget . Один із широко поширених стилів кодування Java передбачає використання UpperCamelCase для класів і lowerCamelCase використовуватися для примірників (instances) і методів.[25] Визнаючи таке використання, деякі IDE, такі як Eclipse, реалізують ярлики на основі CamelCase. Наприклад, у функції content assist Eclipse введення лише великих літер слова CamelCase запропонує будь-яке відповідне ім’я класу чи методу (наприклад, введення «NPE» та активація content assist може запропонувати NullPointerException ). Ініціалізація з трьох або більше літер — CamelCase замість верхнього регістру (наприклад, parseDbmXmlFromIPAddress замість parseDBMXMLFromIPAddress). Можна також встановити межу на дві або більше букв (наприклад parseDbmXmlFromIpAddress).

JavaScript[ред. | ред. код]

Вбудовані бібліотеки JavaScript використовують ті самі правила іменування, що й Java. Типи даних і функції конструктора використовують верхній регістр (RegExp, TypeError, XMLHttpRequest, DOMObject), а методи використовують нижній регістр (getElementById, getElementsByTagNameNS, createCDATASection). Щоб бути послідовними, більшість розробників JavaScript дотримуються цих умов.[28] Дивіться також: Конвенції Дугласа Крокфорда

Lisp[ред. | ред. код]

Загальною практикою в більшості діалектів Lisp є використання тире для розділення слів в ідентифікаторах, як у with-open-file та make-hash-table. Імена динамічних змінних зазвичай починаються і закінчуються зірочками: *map-walls*. Назви констант позначені знаком плюс: +map-size+.[29][30]

. NET[ред. | ред. код]

Microsoft .NET рекомендує UpperCamelCase, також відомий як PascalCase, для більшості ідентифікаторів. (lowerCamelCase рекомендовано для параметрів і змінних) і є спільною угодою для .NET мови.[31] Корпорація Майкрософт також рекомендує не використовувати підказки щодо префіксів типів (також відомі як Угорська нотація).[32] Замість використання угорської нотації рекомендується закінчувати назву назвою базового класу; LoginButton замість BtnLogin.[33]

Objective-C[ред. | ред. код]

Objective-C має загальний стиль кодування, який сягає корінням у Smalltalk. Сутності верхнього рівня, включаючи класи, протоколи, категорії, а також конструкції C, які використовуються в програмах Objective-C, як-от глобальні змінні та функції, мають верхній регістр із коротким префіксом у верхньому регістрі, що позначає простір імен, наприклад NSString, UIAppDelegate, NSApp або CGRectMake . Константи можуть мати префікс малої літери «k», наприклад kCFBooleanTrue .

Змінні екземпляра об'єкта використовують lowerCamelCase із префіксом підкреслення, як-от _delegate та _tableView .

Назви методів використовують кілька частин нижнього регістру CamelCase, розділених двокрапками, які розмежовують аргументи, наприклад: application:didFinishLaunchingWithOptions: stringWithFormat: і isRunning .

Pascal, Modula-2 і Oberon[ред. | ред. код]

У мовах Wirthian Pascal, Modula-2 і Oberon зазвичай використовуються ідентифікатори з Capitalized або UpperCamelCase для програм, модулів, констант, типів і процедур, а lowerCamelCase ідентифікатори в lowercase або в нижньому регістрі для математичних констант, змінних, формальних параметрів і функцій.[34] У той час як деякі діалекти підтримують підкреслення та знаки долара в ідентифікаторах, регістр «змія» та регістр макросів, швидше за все, обмежуються використанням в іноземних інтерфейсах API.[35]

Perl[ред. | ред. код]

Perl бере деякі ознаки своєї спадщини C для конвенцій. Назви локальних змінних і підпрограм пишуться малими літерами з інфіксним підкресленням. Підпрограми та змінні, призначені для обробки як приватні, мають префікс підкреслення. Змінні пакета виділяються в регістр заголовків. Усі оголошені константи мають великі літери. Назви пакетів пишуться регістром, за винятком прагмат, наприклад strict і mro, які пишуться малими літерами.[36] [37]

PHP[ред. | ред. код]

Рекомендації PHP містяться в PSR-1 (стандартна рекомендація PHP 1) і PSR-12.[38] Згідно з PSR-1, назви класів повинні бути в регістрі Pascal, константи класів повинні бути в MACRO_CASE, а назви функцій і методів повинні бути в верблюдячому регістрі.[39]

Python і Ruby[ред. | ред. код]

Python і Ruby рекомендують UpperCamelCase для назв класів, CAPITALIZED_WITH_UNDERSCORES для констант і snake_case для інших назв.

У Python, якщо ім'я має бути «private», перед ним ставиться один або два символи підкреслення (у Python це більш-менш хак). Приватні змінні застосовуються в Python лише за угодою. Імена також можуть бути суфіксами підкреслення, щоб запобігти конфлікту з ключовими словами Python. Префікс із подвійним підкресленням змінює поведінку в класах щодо викривлення імен. Префікс і з подвійним підкресленням — так звані методи «dunder» («double under») у Python — зарезервовано для «магічних імен», які виконують особливу поведінку в об'єктах Python.[40]

R[ред. | ред. код]

Хоча немає офіційного посібника зі стилю для R, посібник зі стилю tidyverse від R-гуру Хедлі Вікхема встановлює стандарт для більшості користувачів.[41] Цей посібник рекомендує уникати спеціальних символів у назвах файлів і використовувати лише цифри, літери та підкреслення для назв змінних і функцій, напр. fit_models.R.

Raku[ред. | ред. код]

Raku дотримується більш-менш тих самих умов, що й Perl, за винятком того, що він допускає інфіксний дефіс - або апостроф ' (або одиночний цитата) всередині ідентифікатора (але не двох поспіль), за умови, що після нього йде буква. Тому програмісти Raku часто використовують у своїх ідентифікаторах kebab case; наприклад, fish-food і don't-do-that є дійсними ідентифікаторами. [42]

Rust[ред. | ред. код]

Rust рекомендує UpperCamelCase для псевдонімів типів і назв структур, ознак, enum і варіантів enum, SCREAMING_SNAKE_CASE для констант або статики та snake_case для імен членів змінних, функцій і структур.[43]

Swift[ред. | ред. код]

Swift змінив правила іменування з кожним окремим випуском. Однак велике оновлення Swift 3.0 стабілізувало умови іменування для lowerCamelCase у змінних і оголошеннях функцій. Константи зазвичай визначаються типами перерахувань або константними параметрами, які також записуються таким чином. Оголошення класів та інших типів об'єктів є UpperCamelCase.

Починаючи з Swift 3.0, було створено чіткі вказівки щодо іменування мови з метою стандартизації імен і декларацій API для всіх сторонніх API. [44]

Дивитися також[ред. | ред. код]

Примітки[ред. | ред. код]

  1. ↑ Derek M. Jones «Operand names influence operator precedence decisions» An experiment investigating the effect of variable names on operator precedence selection
  2. ↑ Raymond, Eric S. (1 жовтня 2004). religious issues. The Jargon File (вид. version 4.4.8). Процитовано 7 листопада 2011.
  3. ↑ Binkley, Dave; Davis, Marcia (2009). To CamelCase or Under_score (PDF). 2009 IEEE 17th International Conference on Program Comprehension (17): 158—167. doi:10.1109/ICPC.2009.5090039. ISBN 978-1-4244-3998-0.
  4. ↑ Naming a Package
  5. ↑ CSS reference. Mozilla Developer Network. Процитовано 18 червня 2016.
  6. ↑ StackOverflow – What's the name for snake_case with dashes?.
  7. ↑ Programmers – If this is camelCase what-is-this?. Архів оригіналу за 7 серпня 2016. Процитовано 27 січня 2023.
  8. ↑ Camel_SNAKE-kebab. GitHub. September 2019.
  9. ↑ UnderscoreVersusCapitalAndLowerCaseVariableNaming
  10. ↑ jwfearn (5 вересня 2012). Revisions to jwfearn's answer to What's the name for dash-separated case?.
  11. ↑ Living Clojure (2015), by Carin Meier, p. 91
  12. ↑ lodash: kebabCase
  13. ↑ а б в -kinds-of-cases naming - Які бувають різні види випадків?. Stack Overflow. Процитовано 16 серпня 2020.
  14. ↑ Короткий список програмування правила іменування. deanpugh.com (en- GB) . 20 березня 2018. Процитовано 16 серпня 2020.
  15. ↑ PSR-1: Базовий стандарт кодування - PHP-FIG. www.php-fig.org (англ.). {{cite web}}: Проігноровано невідомий параметр |доступ -date= (довідка)
  16. ↑ commons.org/camel-snake-kebab/ camel-snake-kebab. camel-snake-kebab (амер.). Процитовано 16 серпня 2020.
  17. ↑ Making Wrong Code Look Wrong. Joel on Software. 11 травня 2005.
  18. ↑ 3.2.1 Names - Chapter 3 - Ada 95 QUALITY AND STYLE Guide.
  19. ↑ ISO/IEC 9899:1999 Programming languages – C. ISO.
  20. ↑ ISO/IEC 14882:2011 Information technology – Programming languages – C++. ISO.
  21. ↑ Правила іменування. Microsoft.
  22. ↑ Names of Type Members. Microsoft.
  23. ↑ Effective Dart - the Dart Style Guide.
  24. ↑ Effective Go - the Go Programming Language.
  25. ↑ а б «Угоди про код для мови програмування Java», [ http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html Розділ 9: «Угоди про імена»]
  26. ↑ «ПОСІБНИК ЩОДО СТАНДАРТІВ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ NETSCAPE ДЛЯ JAVA», [http ://collaboratory.emsl.pnl.gov/docs/collab/sam/CodeStandards.html [Архівовано 2009-03-03 у Wayback Machine.] Посібник зі стандартів кодування програмного забезпечення Collab для Java] Архівована копія. Архів оригіналу за 3 березня 2009. Процитовано 16 лютого 2023.{{cite web}}: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання)
  27. ↑ .html «Стандарти кодування AmbySoft Inc. для Java v17.01d»[недоступне посилання]
  28. ↑ Morelli, Brandon (17 листопада 2017). 5 JavaScript Style Guides – Including AirBnB, GitHub, & Google. codeburst.io. Процитовано 17 серпня 2018.
  29. ↑ Variables.
  30. ↑ Naming conventions on CLiki
  31. ↑ Стилі використання великих літер Microsoft .NET Framework
  32. ↑ .NET Framework Developer's Guide — General Naming Conventions
  33. ↑ [Інструкції з проектування фреймворку, Кшиштоф Кваліна, Бред Абрамс, сторінка 62]
  34. ↑ Modula-2 Name Convention. Архів оригіналу за 10 вересня 2016. Процитовано 27 січня 2023.
  35. ↑ Foreign API Identifiers in Modula-2 Name Convention. Архів оригіналу за 10 вересня 2016. Процитовано 27 січня 2023.
  36. ↑ Perl style guide.
  37. ↑ perlmodlib – constructing new Perl modules and finding existing ones.
  38. ↑ PHP standards recommendations.
  39. ↑ PSR-1: Basic Coding Standard - PHP-FIG.
  40. ↑ [ https://www.python.org/dev/peps/pep-0008/ Керівництво по стилю для коду Python PEP8]
  41. ↑ tidyverse.org/ Посібник зі стилю для RCode. Архів оригіналу за 30 листопада 2017. Процитовано 27 січня 2023.
  42. ↑ Загальні правила синтаксису Perl 6.
  43. ↑ Назви. doc.rust-lang.org (англ.). Процитовано 4 лютого 2018.
  44. ↑ Інструкції з розробки API swift.org.

Посилання[ред. | ред. код]

  • coding-guidelines.com has a pdf який використовує лінгвістику та психологію для спроби аналізу витрат і вигод щодо проблем іменування ідентифікаторів
Отримано з https://uk.wikipedia.org/w/index.php?title=Узгодження_імен&oldid=41073316