Соглашения об именах (программирование)

Основополагающими элементами всех соглашений об именах являются правила, относящиеся к длине идентификатора (то есть конечному количеству отдельных символов, разрешённых в идентификаторе). Некоторые правила предписывают фиксированную числовую границу, в то время как другие определяют менее точные значения или рекомендации.

Правила длины идентификатора обычно оспариваются на практике и являются предметом многочисленных научных дискуссий.

Некоторые соображения:

• более короткие идентификаторы могут быть предпочтительнее как более целесообразные, потому что их легче вводить (хотя многие IDE и текстовые редакторы обеспечивают завершение текста, что облегчает это);
• очень короткие идентификаторы (такие как 'i' или 'j') очень сложно однозначно отличить с помощью инструментов автоматического поиска и замены (хотя это не проблема для инструментов, основанных на регулярных выражениях);
• более длинные идентификаторы могут быть предпочтительнее, потому что короткие идентификаторы не могут закодировать достаточно информации или кажутся слишком загадочными;
• более длинные идентификаторы могут быть нежелательны из-за визуального беспорядка.

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

Краткость в программировании частично объясняется:

• ранние компоновщики, которые требовали, чтобы имена переменных были ограничены до 6 символов для экономии памяти. Более поздний «прогресс» позволил использовать более длинные имена переменных для понимания человеком, но только первые несколько символов были значимыми. В некоторых версиях BASIC, таких как TRS-80 Level 2 Basic, длинные имена были разрешены, но только первые две буквы были значимыми. Эта функция допускала ошибочное поведение, которое было трудно отладить, например, когда использовались такие имена, как «VALUE» и «VAT»;
• в ранних редакторах исходного кода отсутствует автозаполнение;
• ранние мониторы с низким разрешением и ограниченной длиной строки (например, всего 80 символов);
• большая часть информатики берёт своё начало в математике, где имена переменных традиционно состоят из одной буквы.

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

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

Поскольку большинство языков программирования не допускают использование пробелов в идентификаторах, необходим метод разделения каждого слова (чтобы последующим читателям было легче интерпретировать, какие символы принадлежат какому слову). Исторически некоторые ранние языки, особенно FORTRAN (1955) и ALGOL (1958), допускали пробелы в идентификаторах, определяя конец идентификаторов по контексту. В более поздних языках от этого отказались из-за сложности токенизации. Можно писать имена, просто соединяя слова, и это иногда используется, как в mypackage для имён пакетов Java[9], хотя разборчивость страдает от более длинных терминов, поэтому обычно используется какая-то форма разделения.

Один из подходов — разделить отдельные слова не буквенно-цифровыми символами. Для этой цели обычно используются два символа: дефис («-») и подчёркивание («_»); например, имя из двух слов «two words» будет представлено как «two-words» или «two_words». Дефис используется почти всеми программистами, пишущими на COBOL (1959), Forth (1970) и Lisp (1958); он также распространён в Unix для команд и пакетов и используется в CSS[10]. У этого соглашения нет стандартного названия, хотя оно может называться lisp-case или COBOL-CASE (сравните Pascal case), kebab-case, brochette-case или другими вариантами[11][12][13][14]. Из них кебаб-футляр, датируемый по крайней мере 2012 годом[15], с тех пор стал популярным[16][17].

Напротив, языки в традиции FORTRAN / ALGOL, особенно языки семейств C и Pascal, использовали дефис для инфиксного оператора вычитания и не хотели требовать пробелов вокруг него (как языки свободной формы), предотвращая его использование в идентификаторы. Альтернативой является использование подчёркивания; это распространено в семействе C (включая Python), где слова в нижнем регистре встречаются, например, в языке программирования C (1978) и стали известны как змеиный регистр. Подчёркивания с прописными буквами, как в UPPER_CASE, обычно используются для макросов препроцессора C, поэтому они известны как MACRO_CASE, и для переменных среды в Unix, таких как BASH_VERSION в bash. Иногда это с юмором называют SCREAMING_SNAKE_CASE.

Другой подход состоит в том, чтобы указать границы слов с использованием средних заглавных букв, называемых «camelCase», «Pascal case» и многих других имён, таким образом, соответственно отображая «two words» как «twoWords» или «TwoWords». Это соглашение обычно используется в Pascal, Java, C # и Visual Basic. Обработка инициализмов в идентификаторах (например, «XML» и «HTTP» в XMLHttpRequest) варьируется. Некоторые считают, что они должны быть в нижнем регистре (например, XmlHttpRequest), чтобы упростить набор текста и удобочитаемость, тогда как другие оставляют их в верхнем регистре (например, XMLHTTPRequest) для точности.

Возможно, наиболее известной является венгерская нотация, которая кодирует либо назначение («Apps Hungarian»), либо тип («Systems Hungarian») переменной в её имени[22]. Например, префикс «sz» для переменной szName указывает, что переменная является строкой с завершающим нулём.

Стиль, используемый для очень коротких (восемь символов и менее), может быть следующим: LCCIIL01, где LC — это приложение (аккредитивы), C для COBOL, IIL для конкретного подмножества процессов, а 01 — порядковый номер.

Такое соглашение все ещё активно используется в мэйнфреймах, зависящих от JCL, а также встречается в стиле MS-DOS 8.3 (максимум восемь символов с разделяющей точкой, за которой следует трёхсимвольный тип файла).

«OF Language» IBM был задокументирован в руководстве по IMS (системе управления информацией).

В нём подробно описана словесная схема PRIME-MODIFIER-CLASS, которая состоит из таких имён, как «CUST-ACT-NO» для обозначения «номера счёта клиента».

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

Слова МОДИФИКаТОР использовались для дополнительного уточнения, уточнения и удобочитаемости.

В идеале слова CLASS были бы очень коротким списком типов данных, относящихся к конкретному приложению. Общие слова CLASS могут быть: NO (число), ID (идентификатор), TXT (текст), AMT (сумма), QTY (количество), FL (флаг), CD (код), W (работа) и т. д. На практике доступные слова КЛаССа будут списком из менее чем двух десятков терминов.

Слова CLASS, которые обычно располагаются справа (суффикс), служат почти той же цели, что и префиксы венгерских обозначений.

Назначение слов CLASS, помимо согласованности, состояло в том, чтобы указать программисту тип данных конкретного поля данных. Перед принятием полей BOOLEAN (только два значения) FL (флаг) будет указывать на поле только с двумя возможными значениями.

Adobe Coding Conventions and Best Practices предлагает стандарты именования для ActionScript, которые в основном соответствуют стандартам ECMAScript. Стиль идентификаторов похож на стиль Java.

В Ada единственный рекомендуемый стиль идентификаторов — Mixed_Case_With_Underscores[23].

В диалектах APL между словами используется дельта (Δ), например PERFΔSQUARE (в старых версиях APL строчных букв традиционно не было). Если в названии используются подчёркнутые буквы, то вместо них будет использоваться подчёркиваемая дельта-черта (⍙).

В C и C++ ключевые слова и идентификаторы стандартной библиотеки в основном записываются в нижнем регистре. В стандартной библиотеке C сокращённые имена являются наиболее распространёнными (например, isalnum для функции, проверяющей, является ли символ буквенно-цифровым), в то время как стандартная библиотека C++ часто использует подчёркивание в качестве разделителя слов (например, out_of_range). Идентификаторы, представляющие макросы, по соглашению записываются с использованием только прописных букв и подчёркиваний (это связано с соглашением во многих языках программирования об использовании идентификаторов только в верхнем регистре для констант). Имена, содержащие двойное подчёркивание или начинающиеся с подчёркивания и заглавной буквы, зарезервированы для реализации (компилятор, стандартная библиотека) и не должны использоваться (например, __reserved или _Reserved)[24][25]. Это внешне похоже на строппинг, но семантика различается: подчёркивания являются частью значения идентификатора, а не заключают в кавычки символы (как строппинг): значение __foo равно __foo (которое зарезервировано), а не foo (но в другом пространстве имён).

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

В руководстве Microsoft рекомендует исключительное использование только PascalCase и CamelCase, причём последний используется только для имён параметров и имён переменных метода локальных (включая метод локального const) значений. Специальное исключение для PascalCase сделано для двухбуквенных акронимов, которые начинают идентификатор; в этих случаях обе буквы IOStream буквы (например, IOStream); это не относится к более длинным акронимам (например, XmlStream). В руководстве также рекомендуется, чтобы имя, данное interface было PascalCase, которому предшествовала заглавная буква I, как в IEnumerable .

Рекомендации Microsoft по именованию полей относятся к static, public и protected полям; поля, которые не являются static и имеют другие уровни доступности (например, internal и private), явно не подпадают под действие рекомендаций[27]. Наиболее распространённой практикой является использование PascalCase для имён всех полей, за исключением тех, которые являются private (и не являются ни const, ни static), которым присваиваются имена, в которых используется camelCase, которому предшествует одиночный знак подчёркивания; например, _totalCount.

Любое имя идентификатора может начинаться с символа коммерческого предложения (@) без изменения значения. То есть и factor, и @factor относятся к одному и тому же объекту. По соглашению этот префикс используется только в тех случаях, когда идентификатор в противном случае был бы либо зарезервированным ключевым словом (например, for и while), которое нельзя использовать в качестве идентификатора без префикса, либо контекстным ключевым словом (например, from и where), и в этих случаях префикс не требуется строго (по крайней мере, не при его объявлении; например, хотя объявление dynamic dynamic; действительно, это обычно рассматривается как dynamic @dynamic;, чтобы сразу указать читателю, что последнее является именем переменной).

В Go принято использовать MixedCaps или mixedCaps, а не подчёркивание для написания многословных имён. При ссылке на классы или функции первая буква указывает видимость для внешних пакетов. Если сделать первую букву в верхнем регистре, этот фрагмент кода будет экспортирован, а в нижнем регистре он будет использоваться только в текущей области[28].

В Java соглашения об именах для идентификаторов были разработаны и предложены различными сообществами Java, такими как Sun Microsystems[29], Netscape[30], AmbySoft[31] и т. д. Примеры соглашений об именах, установленных Sun Microsystems, перечислены ниже, где имя в «CamelCase» состоит из нескольких слов, соединённых без пробелов, с начальной прописной буквой каждого слова, например «CamelCase».

Компиляторы Java не применяют эти правила, но несоблюдение их может привести к путанице и ошибочному коду. Например, widget.expand() и Widget.expand() предполагают существенно различное поведение: widget.expand() подразумевает вызов метода expand() в экземпляре с именем widget, тогда как Widget.expand() подразумевает вызов статического метода. expand() в классе Widget .

Один широко используемый стиль кодирования Java требует, чтобы UpperCamelCase использовался для классов, а lowerCamelCase — для экземпляров и методов[29]. Признавая такое использование, некоторые IDE, такие как Eclipse, реализуют ярлыки на основе CamelCase. Например, в функции поддержки содержимого Eclipse ввод только заглавных букв слова CamelCase будет предлагать любое подходящее имя класса или метода (например, ввод «NPE» и активация помощника по содержимому может предложить NullPointerException).

Инициализмы из трёх или более букв — CamelCase вместо прописных (например, parseDbmXmlFromIPAddress вместо parseDBMXMLFromIPAddress). Также можно установить границу из двух или более букв (например, parseDbmXmlFromIpAddress).

Встроенные библиотеки JavaScript используют те же соглашения об именах, что и Java. Типы данных и функции конструктора используют верхний регистр (RegExp, TypeError, XMLHttpRequest, DOMObject), а методы используют нижний регистр (getElementById, getElementsByTagNameNS, createCDATASection). Чтобы быть последовательными, большинство разработчиков JavaScript следуют этим соглашениям[32][33].

Обычной практикой в большинстве диалектов Лиспа является использование дефисов для разделения слов в идентификаторах, как в with-open-file и make-hash-table. Имена динамических переменных обычно начинаются и заканчиваются звёздочками: *map-walls*. Имена констант отмечены знаком плюс: +map-size+[34][35].

Microsoft .NET рекомендует UpperCamelCase, также известный как PascalCase, для большинства идентификаторов. Для параметров и переменных рекомендуется использовать lowerCamelCase), что является общим соглашением для .NET языков[36]. Microsoft также рекомендует не использовать подсказки префиксов типа (также известные как венгерская нотация[37]. Вместо использования венгерской нотации рекомендуется заканчивать имя именем базового класса: LoginButton вместо BtnLogin[38].

Objective-C имеет общий стиль программирования, уходящий корнями в Smalltalk.

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

Переменные объекта используют lowerCamelCase с префиксом подчёркивания, например _delegate и _tableView.

Имена методов используют несколько частей lowerCamelCase, разделённых двоеточиями, которые разделяют аргументы, например: application: didFinishLaunchingWithOptions:, stringWithFormat: и isRunning.

Языки Pascal, Modula-2 и Oberon обычно используют идентификаторы Capitalized или UpperCamelCase для программ, модулей, констант, типов и процедур, а lowerCamelCase идентификаторы lowercase или lowerCamelCase для математических констант, переменных, формальных параметров и функций[39]. В то время как некоторые диалекты поддерживают символы подчёркивания и доллара в идентификаторах, регистр змейки и регистр макроса, скорее всего, ограничены использованием в интерфейсах внешнего API[40].

Perl берёт некоторые правила из своего наследия C. Имена переменных и подпрограмм с локальной областью видимости пишутся строчными буквами с инфиксными символами подчёркивания. Подпрограммы и переменные, которые должны рассматриваться как частные, имеют префикс подчёркивания. Переменные пакета заключены в заголовок. Все объявленные константы заглавными. Имена пакетов записываются в верхнем регистре, за исключением прагмат, например, strict и mro, которые mro записываются в нижнем регистре[41][42].

Рекомендации PHP содержатся в PSR-1 (стандартная рекомендация PHP 1) и PSR-12[43]. Согласно PSR-1, имена классов должны быть в PascalCase, константы классов должны быть в MACRO_CASE, а имена методов должны быть в camelCase[44].

Python и Ruby рекомендуют UpperCamelCase для имён классов, CAPITALIZED_WITH_UNDERSCORES для констант и lowercase_separated_by_underscores для других имён.

В Python, если имя должно быть «приватным» в рамках модуля, его рекомендуется начинать с одного знака подчёркивания. Имена также могут заканчиваться одним подчёркиванием, чтобы предотвратить конфликт с ключевыми словами Python. Префикс же с двойным подчёркиванием искажает внешнее представление имён членов класса: например, в классе FooBar метод __boo снаружи класса будет виден как _FooBar__boo. Имена одновременно начинающиеся и заканчивающиеся двойным подчёркиванием зарезервированы для «магических имён», которые играют особую роль в Python (например, __init__, __import__, __file__)[45].

Хотя официального руководства по стилю для R не существует, руководство по стилю tidyverse от R-гуру Хэдли Викхема устанавливает стандарт для большинства пользователей[46]. В этом руководстве рекомендуется избегать использования специальных символов в именах файлов и использовать только цифры, буквы и символы подчёркивания для имён переменных и функций, например, fit_models. Р.

Raku следует более или менее тем же правилам, что и Perl, за исключением того, что Raku позволяет использовать внутренние дефисы и апострофы (одинарные кавычки), при условии, что за ними всегда идут буквы. Таким образом, в Raku можно использовать kebab-case: например, fish-food и don't-do-that являются допустимыми идентификаторами[47].

Rust рекомендует UpperCamelCase для псевдонимов типов и имён вариантов struct, trait, enum и enum, SCREAMING_SNAKE_CASE для констант или статических переменных и snake_case для имён переменных, функций и структур[48].

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

Начиная с Swift 3.0, были сформулированы чёткие инструкции по именованию для языка с целью стандартизации соглашений об именах и объявлениях API для всех сторонних API[49].