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

Введение

Набор правил для именования сущностей в исходном коде и документации

В компьютерном программировании соглашение об именовании — это набор правил для выбора последовательности символов, используемых для идентификаторов, обозначающих переменные, типы, функции и другие сущности в исходном коде и документации. Причины использования соглашения об именовании (в отличие от предоставления программистам возможности выбирать любую последовательность символов) включают следующее:

Уменьшение усилий, необходимых для чтения и понимания исходного кода;
Возможность сосредоточить внимание при проверке кода на вопросах, более важных, чем синтаксис и стандарты именования. Возможность для инструментов проверки качества кода сосредоточить отчетность в основном на значимых проблемах, не связанных с синтаксисом и стилем. Выбор соглашений об именовании может быть спорным вопросом, сторонники каждого из них считают свои наилучшими, а остальные — худшими. В обиходе это называют вопросом догмы. Многие компании также разработали собственные соглашения.

Вызовы

Выбор соглашений об именовании (и степень их соблюдения) часто является предметом споров, при этом сторонники считают свою точку зрения наилучшей, а остальные – хуже. Более того, даже при наличии известных и чётко определённых соглашений об именовании, некоторые организации могут непоследовательно их придерживаться, что приводит к несогласованности и путанице. Эти проблемы могут усугубляться, если правила именования внутренне противоречивы, произвольны, сложны для запоминания или в целом воспринимаются как более обременительные, чем полезные.

Общие элементы

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

Многосложные идентификаторы

Общая рекомендация – "Используйте осмысленные идентификаторы". Одно слово может оказаться менее осмысленным или конкретным, чем несколько слов. Соответственно, некоторые соглашения об именовании устанавливают правила обработки "составных" идентификаторов, содержащих более одного слова. Поскольку большинство языков программирования не допускают пробелы в идентификаторах, необходим способ разделения слов (чтобы упростить последующим читателям понимание того, какие символы относятся к какому слову). Исторически некоторые ранние языки, в частности FORTRAN (1955) и ALGOL (1958), разрешали пробелы внутри идентификаторов, определяя их конец по контексту. От этой практики отказались в более поздних языках из-за сложности токенизации. Имена можно составлять, просто объединяя слова, и это иногда используется, например, в `mypackage` для имен пакетов Java, однако читаемость ухудшается для более длинных терминов, поэтому обычно применяется какой-либо вид разделителя.

Слова, разделенные делимитером

Один из подходов заключается в разделении отдельных слов неалфавитно-цифровым символом. Два символа, обычно используемые для этой цели, — это дефис ("-") и подчеркивание ("_"); например, составное имя "two words" будет представлено как "two-words" или "two_words". Дефис используется почти всеми программистами, пишущими на COBOL (1959), Forth (1970) и Lisp (1958); он также распространен в Unix для команд и пакетов и используется в CSS. У этой конвенции нет стандартного названия, хотя её можно называть lisp case или COBOL CASE (в сравнении с Pascal case), kebab case, brochette case или другими вариантами. Из них kebab case, появившийся как минимум в 2012 году, с тех пор получил некоторую популярность. В отличие от этого, языки, восходящие к традициям FORTRAN/ALGOL, особенно языки семейств C и Pascal, использовали дефис для инфиксного оператора вычитания и не хотели требовать пробелов вокруг него (как в языках со свободной формой), что препятствовало его использованию в идентификаторах. Альтернативой является использование подчеркиваний; это распространено в семействе C (включая Python), с использованием строчных букв, как, например, в книге «Язык программирования C» (1978), и получило название snake case или snail case. Подчеркивания с использованием заглавных букв, как в UPPER_CASE, обычно используются для макросов препроцессора C, поэтому известны как MACRO CASE, а также для переменных окружения в Unix, таких как BASH_VERSION в bash. Иногда это в шутку называют SCREAMING SNAKE CASE (или SCREAMING SNAIL CASE).

Слова, разделенные на буквы

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

Венгерская обозначение

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

Позиционная обозначение

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

Схема сложных слов (OF Language)

Язык "OF Language" компании IBM был задокументирован в руководстве IMS (Information Management System). В нем подробно описывалась схема именования PRIME MODIFIER CLASS, которая состояла из имен, таких как "CUST ACT NO", для обозначения "номера счета клиента". Слова PRIME предназначались для обозначения основных "объектов", представляющих интерес для системы. Слова MODIFIER использовались для дополнительной детализации, уточнения и повышения читаемости. Слова CLASS в идеале должны представлять собой очень короткий список типов данных, релевантных для конкретного приложения. Распространенные слова CLASS могли быть: NO (число), ID (идентификатор), TXT (текст), AMT (сумма), QTY (количество), FL (флаг), CD (код), W (рабочий) и так далее. На практике, доступный список слов CLASS содержал менее двух десятков терминов. Слова CLASS, обычно располагаемые справа (в качестве суффикса), выполняли ту же функцию, что и префиксы венгерской нотации. Помимо обеспечения согласованности, целью слов CLASS было указать программисту тип данных конкретного поля. До того, как были приняты поля BOOLEAN (только два значения), FL (флаг) указывал на поле, имеющее только два возможных значения.

ActionScript (по умолчанию)

Стандарты кодирования и лучшие практики Adobe рекомендуют стандарты именования для ActionScript, которые в основном соответствуют стандартам ECMAScript. Стиль идентификаторов аналогичен стилю Java.

Эда

В Ada единственным рекомендуемым стилем для идентификаторов является стиль Mixed Case With Underscores.

АПЛ

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

C и C++

В C и C++ ключевые слова и идентификаторы стандартных библиотек в основном пишутся строчными буквами. В стандартной библиотеке C наиболее распространены сокращенные имена (например, `isalnum` для функции, проверяющей, является ли символ буквенно-цифровым), в то время как стандартная библиотека C++ часто использует подчеркивание в качестве разделителя слов (например, `out of range`). Идентификаторы, представляющие макросы, по соглашению пишутся только заглавными буквами и подчеркиваниями (это связано с соглашением, принятым во многих языках программирования, использовать все заглавные идентификаторы для констант). Имена, содержащие двойное подчеркивание или начинающиеся с подчеркивания и заглавной буквы, зарезервированы для реализации (компилятора, стандартной библиотеки) и не должны использоваться (например, `reserved` или `Reserved`). Это поверхностно похоже на стробирование, но семантика отличается: подчеркивания являются частью значения идентификатора, а не символами кавычек (как в стробировании): значение `foo` – это `foo` (которое зарезервировано), а не `foo` (но в другом пространстве имен).

Язык

Названия в C# обычно следуют рекомендациям, опубликованным Microsoft для всех языков .NET (см. раздел .NET ниже), но компилятор C# не применяет никаких соглашений. Руководство Microsoft рекомендует использовать исключительно PascalCase и camelCase, причем последнее применяется только для имен параметров методов и локальных переменных методов (включая локальные константные значения). Особое исключение из PascalCase делается для двухбуквенных аббревиатур, начинающих идентификатор; в этих случаях обе буквы пишутся с заглавной буквы (например, IOStream); это не относится к более длинным аббревиатурам (например, XmlStream). Кроме того, рекомендуется называть интерфейсы PascalCase с добавлением заглавной буквы I в начале, как в IEnumerable. Руководство Microsoft по именованию полей распространяется на статические, открытые и защищенные поля; поля, которые не являются статическими и имеют другие уровни доступа (например, внутренние и закрытые), явно не охватываются этими рекомендациями. Наиболее распространенной практикой является использование PascalCase для имен всех полей, за исключением закрытых полей (которые не являются ни const, ни static), которым присваиваются имена в camelCase, предваренные одним знаком подчеркивания; например, totalCount. Любое имя идентификатора может быть предварено символом «@», не изменяя его значения. То есть, factor и @factor ссылаются на один и тот же объект. По соглашению, этот префикс используется только в тех случаях, когда идентификатор в противном случае был бы либо зарезервированным ключевым словом (например, for и while), которое нельзя использовать в качестве идентификатора без префикса, либо контекстным ключевым словом (например, from и where), в которых префикс не является строго обязательным (по крайней мере, не при объявлении; например, хотя объявление `dynamic dynamic;` допустимо, обычно оно выглядит как `dynamic @dynamic;`, чтобы сразу указать читателю, что последнее является именем переменной).

Иди .

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

Липс

В большинстве диалектов Lisp принято использовать дефисы для разделения слов в идентификаторах, например, `with open file` и `make hash table`. Имена динамических переменных обычно начинаются и заканчиваются звездочками: `*map walls*`. Имена констант обозначаются знаками плюса: `+map size+`.

.NET

Microsoft .NET рекомендует использовать UpperCamelCase, также известный как PascalCase, для большинства идентификаторов (нижнийCamelCase рекомендуется для параметров и переменных) как общую конвенцию для языков .NET. Microsoft также не рекомендует использовать префиксы, указывающие на тип (также известные как венгерская нотация). Вместо венгерской нотации рекомендуется добавлять к имени базовый класс, например, LoginButton вместо BtnLogin.

Цель-С

Objective C имеет общепринятый стиль кодирования, уходящий корнями в Smalltalk. Сущности верхнего уровня, включая классы, протоколы, категории, а также конструкции C, используемые в программах на Objective C, такие как глобальные переменные и функции, пишутся в UpperCamelCase с коротким префиксом в верхнем регистре, обозначающим пространство имен, например, NSString, UIAppDelegate, NSApp или CGRectMake. Константы могут опционально начинаться с маленькой буквы "k", например, kCFBooleanTrue. Переменные экземпляра объекта используют lowerCamelCase с префиксом в виде подчеркивания, например, delegate и tableView. Имена методов состоят из нескольких частей в lowerCamelCase, разделенных двоеточиями, которые разделяют аргументы, например: application:didFinishLaunchingWithOptions:, stringWithFormat: и isRunning.

Паскаль, Модула-2 и Оберон

Языки Вирта Паскаль, Модула-2 и Оберон обычно используют идентификаторы с заглавной буквы или UpperCamelCase для программ, модулей, констант, типов и процедур, а строчные буквы или lowerCamelCase — для математических констант, переменных, формальных параметров и функций. Хотя некоторые диалекты поддерживают использование символов подчеркивания и знаков доллара в идентификаторах, snake_case и macro_case чаще встречаются при работе с иностранными API.

Перл

Perl заимствует некоторые соглашения из своего наследия, восходящего к C. Локальные переменные и имена подпрограмм пишутся строчными буквами с использованием дефисов. Подпрограммы и переменные, предназначенные для использования как приватные, имеют префикс в виде подчеркивания. Переменные пакетов пишутся с заглавной буквы в начале каждого слова. Объявленные константы пишутся полностью заглавными буквами. Имена пакетов пишутся в стиле camelCase, за исключением прагм — например, strict и mro — которые пишутся строчными буквами.

PHP (англ.)

Рекомендации PHP содержатся в PSR 1 (PHP Standard Recommendation 1) и PSR 12. Согласно PSR 1, имена классов должны быть написаны в стиле PascalCase, константы классов – в стиле MACRO CASE, а имена функций и методов – в стиле camelCase.

Python и Ruby

Python и Ruby рекомендуют использовать UpperCamelCase для имен классов, имена в ВЕРХНЕМ РЕГИСТРЕ С ПОДЧЕРКИВАНИЯМИ для констант и snake_case для остальных имен. В Python, если имя предназначено быть "приватным", перед ним ставится одно или два подчеркивания. Приватные переменные в Python обеспечиваются только соглашением. Имена также могут быть дополнены подчеркиванием в конце, чтобы избежать конфликта с ключевыми словами Python. Использование двойного подчеркивания изменяет поведение классов в отношении маскировки имен. Префикс и суффикс с двойным подчеркиванием – так называемые методы "dunder" ("double under") в Python – зарезервированы для "магических методов", которые обеспечивают специальное поведение объектов Python.

R. В

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

Раку

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

Ржавчина

Rust рекомендует UpperCamelCase для псевдонимов типов и имён структур, трейтов, перечислений и вариантов перечислений, SCREAMING SNAKE CASE для констант и статических переменных, а также snake_case для переменных, функций и имён членов структур.

Стрелец

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