Войти
В компьютерном программировании соглашение об именах представляет собой набор правил для выбора последовательности символов, которая будет использоваться для идентификаторов, которые обозначают переменные, типы, функции и другие объекты в источнике код и документация.
Причины использования соглашения об именах (в отличие от разрешения программистам выбирать любую последовательность символов) включают следующее:
Выбор соглашения об именах может быть чрезвычайно спорным вопросом, при этом сторонники каждого считают свои лучшие, а другие худшие. Говорят, что в просторечии это вопрос догмы. Многие компании также установили свои собственные соглашения.
Некоторые из потенциальных преимуществ, которые можно получить, приняв соглашение об именах, включают следующее:
Выбор соглашения об именах (и степень, в которой они применяются) часто является спорным вопросом, когда сторонники придерживаются своей точки зрения как лучшей, а другие - как низшей. Более того, даже при наличии известных и четко определенных соглашений об именах некоторые организации могут не соблюдать их последовательно, вызывая непоследовательность и путаницу. Эти проблемы могут усугубиться, если правила соглашения об именах внутренне непоследовательны, произвольны, трудны для запоминания или иным образом воспринимаются как более обременительные, чем полезные.
Правильно подобранные идентификаторы значительно упрощают разработчикам и аналитикам понимание того, что делает система и как исправить или расширить исходный код, на который необходимо подать заявку новые потребности.
Например, хотя
a = b * c;
является синтаксически правильным, его назначение неочевидно. Сравните это со следующим:
weekly_pay = hours_worked * hourly_pay_rate;
, который подразумевает намерение и значение исходного кода, по крайней мере, для тех, кто знаком с контекстом утверждения.
Точные правила соглашения об именах зависят от контекста, в котором они используются. Тем не менее, есть несколько общих элементов, которые влияют больше всего, если не на все общепринятые сегодня соглашения об именах.
Фундаментальными элементами всех соглашений об именах являются правила, относящиеся к длине идентификатора (т.е. конечному количеству отдельных символов, разрешенных в идентификаторе). Некоторые правила предписывают фиксированную числовую границу, в то время как другие определяют менее точные эвристики или рекомендации.
Правила длины идентификатора обычно оспариваются на практике и являются предметом многочисленных научных дискуссий.
Некоторые соображения:
Это открытый вопрос исследования, предпочитают ли некоторые программисты более короткие идентификаторы, потому что они легче напечатать или придумать, чем более длинные идентификаторы, или потому что во многих ситуациях более длинный идентификатор просто загромождает видимый код и не дает ощутимых дополнительных преимуществ.
Краткость программирования частично объясняется:
Некоторые Соглашения об именах ограничивают отображение букв в верхнем или нижнем регистре. Другие соглашения не ограничивают регистр букв, но дают четко определенную интерпретацию, основанную на регистре букв. Некоторые соглашения об именах определяют, могут ли использоваться буквенные, числовые или буквенно-цифровые символы, и если да, то в какой последовательности.
Общая рекомендация - «Используйте значимые идентификаторы». Одно слово может быть не таким значимым или конкретным, как несколько слов. Следовательно, некоторые соглашения об именах определяют правила обработки «составных» идентификаторов, содержащих более одного слова.
Поскольку большинство языков программирования не допускают пробелов в идентификаторах, необходим метод разграничения каждого слова (чтобы последующим читателям было легче интерпретировать, какие символы принадлежат к какому слову). Исторически некоторые ранние языки, в частности FORTRAN (1955) и ALGOL (1958), допускали пробелы в идентификаторах, определяя конец идентификаторов по контексту. В более поздних языках от этого отказались из-за сложности токенизации. Можно писать имена, просто объединяя слова, и это иногда используется, как в mypackageдля имен пакетов Java, хотя разборчивость страдает для более длинных терминов, поэтому обычно используется какая-то форма разделения.
Один из подходов состоит в том, чтобы разделить отдельные слова с помощью не буквенно-цифрового символа. Для этой цели обычно используются два символа: дефис ("-") и подчеркивание ("_"); например, имя из двух слов «два слова» будет представлено как «два слова» или «два_слова». Дефис используется почти всеми программистами, пишущими COBOL (1959), Forth (1970) и Lisp (1958); он также распространен в Unix для команд и пакетов и используется в CSS. У этого соглашения нет стандартного названия, хотя оно может называться lisp-case или COBOL-CASE (сравните регистр Pascal), kebab-case, brochette-case или другими вариантами. Из них kebab-case, датируемый по крайней мере 2012 годом, с тех пор приобрел некоторую актуальность.
Напротив, языки в традиции FORTRAN / ALGOL, особенно языки в C и Семейства Pascal использовали дефис для вычитания инфиксного оператора и не хотели использовать пробелы вокруг него (как языки произвольной формы ), предотвращая его использование в идентификаторах. Альтернативой является использование подчеркивания; это распространено в семействе C (включая Python), где слова в нижнем регистре встречаются, например, в The C Programming Language (1978) и стали известны как snake case. Подчеркивания с прописными буквами, как в UPPER_CASE, обычно используются для макросов препроцессора C, поэтому они известны как MACRO_CASE, и для переменных среды в Unix, таких как BASH_VERSION в bash <113.>. Иногда это с юмором называют SCREAMING_SNAKE_CASE.
Другой подход состоит в том, чтобы указать границы слов с использованием средних заглавных букв, называемых «camelCase », «Pascal case» и многих других имен, таким образом рендеринг «двух слов» соответственно как «twoWords» или «TwoWords». Это соглашение обычно используется в Pascal, Java, C# и Visual Basic. Обработка инициализмов в идентификаторах (например, «XML » и «HTTP » в XMLHttpRequest ) варьируется. Некоторые требуют, чтобы они были в нижнем регистре (например, XmlHttpRequest), чтобы упростить ввод и читаемость, тогда как другие оставляют их в верхнем регистре (например, XMLHTTPRequest) для точности.
| Форматирование | Имя (я) |
|---|---|
два слова | плоский регистр |
TWOWORDS | плоский верхний регистр |
twoWords | (нижний) camelCase, dromedaryCase |
TwoWords | (верхний) CamelCase, PascalCase, StudlyCase |
two_words | случай змеи, случай_падения |
ДВА_СЛОВА | КРИЧАТЬ ЗМЕИ, MACRO_CASE, CONSTANT_CASE |
Два_слова | Camel_Snake_Case |
двухсловный | kebab-case, тире -case, lisp-case |
TWO-WORDS | TRAIN-CASE, COBOL-CASE, SCREAMING-KEBAB-CASE |
Two-Words | Train-Case, HTTP-Header-Case |
Некоторые соглашения об именах представляют правила или требования, которые выходят за рамки требований конкретного проекта или проблемной области, и вместо этого отражают более обширный всеобъемлющий набор принципов, определенных архитектурой программного обеспечения, лежащий в основе язык программирования или другой вид межпроектных методов логия.
Пожалуй, наиболее известной является Венгерская нотация, которая кодирует либо цель («Приложения Венгерский»), либо тип ("Венгерские системы") переменной в его имени. Например, префикс «sz» для переменной szName указывает, что переменная является строкой с завершающим нулем.
Стиль, используемый для очень коротких (восемь символов и менее), может быть: LCCIIL01, где LC - приложение (аккредитивы), C - COBOL, IIL - конкретное подмножество процесса, а 01 - порядковый номер.
Этот вид соглашения все еще активно используется в мэйнфреймах, зависящих от JCL, а также встречается в версии 8.3 (максимум восемь символов с разделителем точек, за которыми следует трехсимвольный тип файла) MS-DOS стиль.
"Язык OF" IBM был задокументирован в руководстве IMS (Система управления информацией ).
Он детализировал схему слов PRIME-MODIFIER-CLASS, которая состояла из таких имен, как «CUST-ACT-NO» для обозначения «номера счета клиента».
Слова PRIME предназначались для обозначения основных «сущностей», представляющих интерес для системы.
Слова МОДИФИКАТОР были использованы для дополнительного уточнения, уточнения и удобочитаемости.
Слова CLASS в идеале были бы очень коротким списком типов данных, относящихся к конкретному приложению. Общие слова CLASS могут быть: NO (число), ID (идентификатор), TXT (текст), AMT (сумма), QTY (количество), FL (флаг), CD (код), W (работа) и т. Д. На практике доступные слова КЛАССА будут списком из менее чем двух дюжин терминов.
Слова КЛАССА, обычно расположенные справа (суффикс), служили почти той же цели, что и префиксы венгерской нотации.
Назначение слов CLASS, помимо согласованности, состояло в том, чтобы указать программисту тип данных конкретного поля данных. Перед принятием полей BOOLEAN (только два значения) FL (флаг) будет указывать на поле только с двумя возможными значениями.
В соглашениях и рекомендациях по кодированию Adobe предлагаются стандарты наименования для ActionScript, которые в основном соответствуют стандартам ECMAScript. Стиль идентификаторов аналогичен стилю идентификаторов Java.
В Ada единственный рекомендуемый стиль идентификаторов - Mixed_Case_With_Underscores.
В диалектах APL дельта (Δ) используется между словами, например PERFΔSQUARE (в более старых версиях APL строчные буквы традиционно отсутствовали). Если в названии используются подчеркнутые буквы, то вместо них будет использоваться подчеркиваемая дельта-черта ().
В C и C ++, ключевые слова и идентификаторы стандартной библиотеки являются в основном строчные. В стандартной библиотеке C сокращенные имена являются наиболее распространенными (например, isalnumдля функции, проверяющей, является ли символ буквенно-цифровым), тогда как в стандартной библиотеке C ++ часто использует подчеркивание в качестве разделителя слов (например, out_of_range). Идентификаторы, представляющие макросы , по соглашению записываются только с использованием прописных букв и подчеркиваний (это связано с соглашением во многих языках программирования об использовании идентификаторов только в верхнем регистре для констант). Имена, содержащие двойное подчеркивание или начинающиеся с подчеркивания и заглавной буквы, зарезервированы для реализации (компилятор, стандартная библиотека ) и не должны использоваться (например, __reservedили _зарезервировано). Это внешне похоже на сглаживание, но семантика отличается: подчеркивания являются частью значения идентификатора, а не являются символами кавычек (как сглаживание): значение __fooэто __foo(который зарезервирован), а не foo(но в другом пространстве имен).
C# обычно соответствуют рекомендациям, опубликованным Microsoft для всех языков.NET (см. Раздел.NET ниже), но компилятор C # не применяет никаких соглашений.
Рекомендации Microsoft рекомендуют исключительное использование только PascalCase и camelCase , причем последний используется только для метода имена параметров и имена переменных, локальных для метода (включая значения для локального метода const). Специальное исключение для PascalCase сделано для двухбуквенных акронимов, которые начинают идентификатор; в этих случаях обе буквы начинаются с заглавной буквы (например, IOStream); это не относится к более длинным акронимам (например, XmlStream). В рекомендациях также рекомендуется, чтобы имя, данное интерфейсу , было PascalCase, которому предшествовала заглавная буква I, как в IEnumerable.
. поля именования относятся к статическим, общедоступными защищеннымполям; поля, которые не являются статическимии имеют другие уровни доступа (например, внутреннийи частный), явно не подпадают под действие рекомендаций. Наиболее распространенная практика - использовать PascalCaseдля имен всех полей, кроме тех, которые являются private(и ни const, ни static), которым присваиваются имена, в которых используется camelCase, которому предшествует одиночный знак подчеркивания; например, _totalCount.
Любое имя идентификатора может начинаться с символа коммерческого адреса (@) без каких-либо изменений значения. То есть и factor, и @factorотносятся к одному и тому же объекту. По соглашению этот префикс используется только в тех случаях, когда идентификатор в противном случае был бы либо зарезервированным ключевым словом (например, дляи в то время как), который не может использоваться в качестве идентификатора без префикс или контекстное ключевое слово (например, изи , где), и в этих случаях префикс не требуется строго (по крайней мере, не при его объявлении; например, хотя объявление динамический динамический;допустимо, это обычно рассматривается как динамический @dynamic;, чтобы сразу указать читателю, что последнее является именем переменной).
В Go принято использовать или mixedCapsвместо символов подчеркивания для написания многословных имен. При ссылке на классы или функции первая буква указывает видимость для внешних пакетов. Первая буква в верхнем регистре экспортирует этот фрагмент кода, в то время как нижний регистр позволяет использовать его только в пределах текущей области.
В Java соглашения об именах для идентификаторов были установлены и предложены различными сообществами Java, такими как Sun Microsystems, Netscape, AmbySoft и т. д. Ниже приведены примеры соглашений об именах, установленных Sun Microsystems, где имя в «CamelCase » состоит из числа слов, соединенных без пробелов, с заглавными буквами каждого слова, например "CamelCase".
| Тип идентификатора | Правила присвоения имен | Примеры |
|---|---|---|
| Классы | Имена классов должны быть существительными в Верхнем CamelCase , первая буква каждого слова должна быть заглавной. Используйте целые слова - избегайте акронимов и сокращений (если только аббревиатура не используется гораздо шире, чем длинная форма, такая как URL или HTML). |
|
| Methods | Методы должны быть глаголами в lowerCamelCase или многословным именем, которое начинается с глагола в нижнем регистре; то есть с первой буквой в нижнем регистре и первыми буквами последующих слов в верхнем регистре. |
|
| Переменные | Локальные переменные, переменные экземпляра и переменные класса также записываются в lower CamelCase . Имена переменных не должны начинаться с символа подчеркивания (_) или знака доллара ($), даже если и то и другое разрешено. Это контрастирует с другими соглашениями о кодировании, в которых говорится, что подчеркивания должны использоваться для префикса всех переменных экземпляра. Имена переменных должны быть короткими, но содержательными. Выбор имени переменной должен быть мнемоническим - то есть, предназначенным для указания случайному наблюдателю намерения его использования. Следует избегать односимвольных имен переменных, за исключением временных «одноразовых» переменных. Общие имена временных переменных: i, j, k, m и n для целых чисел; c, d и e для символов. |
|
| Константы | Константы следует записывать прописными буквами, разделенными символами подчеркивания. При необходимости имена констант могут также содержать цифры, но не в качестве первого символа. |
|
компиляторы Java не применяют эти правила, но несоблюдение их может привести к путанице и ошибочному коду. Например, widget.expand ()и Widget.expand ()подразумевают существенно различное поведение: widget.expand ()подразумевает вызов метода expand ()в экземпляре с именем widget, тогда как Widget.expand ()подразумевает вызов статического метода expand ()в классе Виджет.
Один широко используемый стиль кодирования Java диктует, что UpperCamelCase должен использоваться для классов и lowerCamelCase быть используется для экземпляров и методов. Признавая такое использование, некоторые IDE, такие как Eclipse, реализуют ярлыки на основе CamelCase. Например, в функции Eclipse помощник по содержанию ввод только заглавных букв слова CamelCase предложит любое подходящее имя класса или метода (например, ввод «NPE» и активация помощника по содержанию может предложить NullPointerException).
При инициализации трех или более букв используется CamelCase, а не прописные (например, parseDbmXmlFromIPAddressвместо parseDBMXMLFromIPAddress). Также можно установить границу из двух или более букв (например, parseDbmXmlFromIpAddress).
Встроенные библиотеки JavaScript используют те же соглашения об именах, что и Java. Типы данных и функции конструктора используют верхний регистр верблюда (RegExp, TypeError, XMLHttpRequest, DOMObject), а методы используют нижний регистр верблюда (getElementById, getElementsByTagNameNS, createCDATASection). Чтобы быть последовательными, большинство разработчиков JavaScript следуют этим соглашениям. См. Также: Соглашения Дугласа Крокфорда
Обычной практикой в большинстве диалектов Lisp является использование дефисов для разделения слов в идентификаторах, как в with-open- файли make-hash-table. Имена динамических переменных обычно начинаются и заканчиваются звездочками: * map-Wall *. Имена констант отмечены знаком плюса: + map-size +.
Microsoft.NET рекомендует UpperCamelCase , также известный как PascalCase, для большинство идентификаторов. (lowerCamelCase рекомендуется для параметров и переменных ) и является общим соглашением для языков.NET. Microsoft также рекомендует не использовать подсказки префиксов типа (также известные как венгерская нотация ). Вместо использования венгерской нотации рекомендуется заканчивать имя именем базового класса; LoginButtonвместо BtnLogin.
Objective-C имеет общий стиль кодирования, который уходит корнями в Smalltalk.
сущности верхнего уровня, включая классы, протоколы, категории, а также конструкции C, которые используются в программах Objective-C, такие как глобальные переменные и функции, находятся в UpperCamelCase с коротким префиксом заглавными буквами, обозначающим пространство имен, например NSString, UIAppDelegate, NSAppили CGRectMake. Константы могут дополнительно иметь префикс в виде строчной буквы «k», например kCFBooleanTrue.
Переменные экземпляра объекта используют нижний регистр с префиксом подчеркивания, например _delegateи _tableView.
Имена методов используйте несколько частей lowerCamelCase, разделенных двоеточиями, которые разделяют аргументы, например: application: didFinishLaunchingWithOptions:, stringWithFormat:и isRunning.
Виртские языки Паскаль, Модула-2 и Оберон обычно используют Заглавныеили UpperCamelCaseидентификаторы для программ, модулей, констант, типов и процедур, а также строчныеили lowerCamelCaseидентификаторы математических констант, переменных, формальных параметров и функций. В то время как некоторые диалекты поддерживают символы подчеркивания и доллара в идентификаторах, регистр змейки и регистр макроса, скорее всего, ограничен использованием в интерфейсах внешнего API.
Perl берет некоторые подсказки из своего наследия C для соглашений. Имена переменных и подпрограмм с локальной областью видимости пишутся строчными буквами с инфиксными символами подчеркивания. Подпрограммы и переменные, которые должны рассматриваться как частные, имеют префикс подчеркивания. Переменные пакета заключены в заголовок. Все объявленные константы заглавными. Имена пакетов записаны в верблюжьем регистре, за исключением прагмат, например, strictи mro , которые в нижнем регистре.
Рекомендации PHP содержатся в PSR-1 (Стандартные рекомендации PHP 1) и PSR-12. Согласно PSR-1, имена классов должны быть в PascalCase, константы классов должны быть в MACRO_CASE, а имена методов должны быть в camelCase.
Python и Ruby оба рекомендуют UpperCamelCaseдля имен классов, CAPITALIZED_WITH_UNDERSCORESдля констант и lowercase_separated_by_underscoresдля других имен.
В Python, если имя предназначено для "private ", оно предваряется знаком подчеркивания. Частные переменные применяются в Python только по соглашению. Имена также могут иметь суффикс с подчеркиванием, чтобы предотвратить конфликт с ключевыми словами Python. Префикс с двойным подчеркиванием изменяет поведение классов в отношении изменения имени. Префикс и суффикс с двойным подчеркиванием зарезервированы для "волшебных имен", которые выполняют особое поведение в объектах Python.
Хотя официального руководства по стилю для R не существует, руководство по стилю tidyverse от R-гуру Хэдли Викхема устанавливает стандарт для большинства пользователей. В этом руководстве рекомендуется избегать использования специальных символов в именах файлов и использовать только цифры, буквы и символы подчеркивания для имен переменных и функций, например. fit_models.R.
Raku следует более или менее тем же правилам, что и Perl, за исключением того, что он позволяет использовать инфиксный дефис - или апостроф (или одинарную кавычку) внутри идентификатора (но не двух в row) при условии, что за ней следует буквенный символ. Таким образом, программисты Raku часто используют регистр kebab в своих идентификаторах; например, корм для рыби не делай этого- допустимые идентификаторы.
Rust рекомендует UpperCamelCaseдля псевдонимов типов и имен вариантов struct, trait, enum и enum, SCREAMING_SNAKE_CASEдля констант или статики и snake_caseдля имен переменных, функций и структур.
Swift меняет свои соглашения об именах с каждым отдельным выпуском. Однако крупное обновление Swift 3.0 стабилизировало соглашения об именах для lowerCamelCaseв переменных и объявлениях функций. Константы обычно определяются перечисляемыми типами или постоянными параметрами, которые также записываются таким образом. Объявления классов и других типов объектов: UpperCamelCase.
Начиная с Swift 3.0, были сформулированы четкие правила именования для языка в попытке стандартизировать соглашения об именах и объявлениях API для всех сторонних API.
