Соглашение об именах (программирование) - Naming convention (programming)

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

Причины использования соглашения об именах (в отличие от разрешения программисты для выбора любой последовательности символов) включают следующее:

• Чтобы уменьшить усилия, необходимые для чтения и понимания исходного кода;^[1]
• Чтобы позволить обзорам кода сосредоточиться на более важных вопросах, чем споры о синтаксисе и стандартах именования.
• Чтобы позволить инструментам проверки качества кода сосредоточить свои отчеты в основном на важных проблемах, помимо синтаксиса и предпочтений стиля.

Выбор соглашения об именах может быть чрезвычайно спорным вопросом, при этом сторонники каждого считают свои лучшие, а другие - худшие. Говорят, что в просторечии это вопрос догма.^[2] Многие компании также установили свои собственные соглашения.

Потенциальные выгоды

Некоторые из потенциальных преимуществ, которые можно получить, приняв соглашение об именах, включают следующее:

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

Вызовы

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

Читаемость

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

Например, хотя

 а = б * c;

является синтаксически правильно, его назначение неочевидно. Сравните это с:

 weekly_pay = отработанные часы * hourly_pay_rate;

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

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

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

Длина идентификаторов

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

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

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

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

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

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

• рано линкеры что требовало ограничения имен переменных до 6 символов для экономии памяти. Более поздний «прогресс» позволил использовать более длинные имена переменных для понимания человеком, но только первые несколько символов были значимыми. В некоторых версиях БАЗОВЫЙ Например, TRS-80, уровень 2, базовый, длинные имена разрешены, но только первые две буквы имеют значение. Эта функция допускала ошибочное поведение, которое было трудно отладить, например, когда имена, такие как «VALUE» и «VAT», использовались и предназначались для различения.
• рано редакторы исходного кода не хватает автозаполнение
• ранние мониторы с низким разрешением с ограниченной длиной строки (например, всего 80 символов)
• большая часть компьютерных наук берет свое начало в математике, где имена переменных традиционно состоят из одной буквы

Регистр букв и цифры

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

Идентификаторы из нескольких слов

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

Как самый языки программирования не позволяйте пробел в идентификаторах необходим метод разграничения каждого слова (чтобы последующим читателям было легче интерпретировать, какие символы относятся к какому слову). Исторически некоторые ранние языки, особенно FORTRAN (1955) и АЛГОЛ (1958), разрешенные пробелы в идентификаторах, определение конца идентификаторов по контексту. В более поздних языках от этого отказались из-за сложности токенизация. Можно писать имена, просто объединяя слова, и это иногда используется, как в мой пакет для имен пакетов Java,^[3] хотя разборчивость ухудшается для более длительных сроков, поэтому обычно используется какая-либо форма разделения.

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

Один из подходов - разграничивать отдельные слова с не буквенно-цифровой персонаж. Для этой цели обычно используются два символа: дефис ("-") и подчеркивать ("_"); например, имя из двух слов "два слова"будет представлен как"два слова" или же "два слова". Дефис используется почти всеми программистами, пишущими КОБОЛ (1959), Четвертый (1970), и Лисп (1958); это также распространено в Unix для команд и пакетов и используется в CSS.^[4] У этого соглашения нет стандартного названия, хотя его можно назвать шепелявый случай или же COBOL-CASE (сравнивать Случай Паскаля), шашлык, портмоне для брошюр, или другие варианты.^[5][6][7][8] Из этих, шашлык, датируемые как минимум 2012 годом,^[9] с тех пор получил некоторую валюту.^[10][11]

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

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

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

Примеры форматов многословных идентификаторов

Метаданные и гибридные соглашения

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

Венгерская нотация

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

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

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

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

Составная схема слов (OF Language)

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

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

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

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

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

Слова КЛАССА, обычно расположенные справа (суффикс), служили почти той же цели, что и Венгерская нотация префиксы.

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

Конкретные языковые соглашения

ActionScript

Adobe Coding Conventions and Best Practices предлагает стандарты именования для ActionScript которые в основном соответствуют ECMAScript.^{[нужна цитата ]} Стиль идентификаторов аналогичен стилю Ява.

Ада

В Ада, единственный рекомендуемый стиль идентификаторов - Mixed_Case_With_Underscores.^[17]

APL

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

C и C ++

В C и C ++, ключевые слова и стандартная библиотека идентификаторы в основном строчные. в Стандартная библиотека C, сокращенные имена являются наиболее распространенными (например, isalnum для функции, проверяющей, является ли символ буквенно-цифровым), а Стандартная библиотека C ++ часто использует подчеркивание в качестве разделителя слов (например, вне диапазона). Идентификаторы, представляющие макросы по соглашению записываются с использованием только прописных букв и подчеркиваний (это связано с соглашением во многих языках программирования об использовании идентификаторов только в верхнем регистре для констант). Имена, содержащие двойное подчеркивание или начинающиеся с подчеркивания и заглавной буквы, зарезервированы для реализации (компилятор, стандартная библиотека ) и не должны использоваться (например, __зарезервированный или же _Зарезервированный).^[18][19] Это внешне похоже на строппинг, но семантика различается: символы подчеркивания являются частью значения идентификатора, а не являются символами кавычек (как в случае штриховки): значение __foo является __foo (что зарезервировано), а не фу (но в другом пространстве имен).

C #

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

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

Рекомендации Microsoft по именованию полей относятся к статический, общественный, и защищенный поля; поля, которые не статический и у которых есть другие уровни доступности (например, внутренний и частный) явно не подпадают под действие рекомендаций.^[21] Наиболее распространенная практика - использовать PascalCase для названий всех полей, кроме тех, которые частный (и ни const ни статический), которым даны имена, использующие верблюд предваряется одиночным подчеркиванием; Например, _общее количество.

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

Идти

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

Ява

В Ява, соглашения об именах для идентификаторов были установлены и предложены различными сообществами Java, такими как Sun Microsystems,^[23] Netscape,^[24] AmbySoft,^[25] и т. д. Примеры соглашений об именах, установленных Sun Microsystems, перечислены ниже, где имя в "CamelCase "состоит из нескольких слов, соединенных без пробелов, с заглавными буквами каждого слова, например" CamelCase ".

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

Один широко используемый стиль кодирования Java диктует, что Верхняя Верблюд использоваться для классы и lowerCamelCase использоваться для экземпляры и методы.^[23]Признавая это использование, некоторые Иды, Такие как Затмение, реализовать ярлыки на основе CamelCase. Например, в Eclipse помощь по содержанию функция, ввод только заглавных букв слова CamelCase предложит любое подходящее имя класса или метода (например, ввод "NPE" и активация помощника по содержанию может предложить Исключение нулевого указателя).

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

JavaScript

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

Лисп

Обычная практика в большинстве Лисп диалекты - использовать тире для разделения слов в идентификаторах, как в с открытым файлом и make-hash-table. Имена динамических переменных обычно начинаются и заканчиваются звездочками: * карты-стены *. Имена констант отмечены знаком плюса: + размер карты +.^[27][28]

.СЕТЬ

Microsoft .NET рекомендует Верхняя Верблюд, также известный как PascalCase, для большинства идентификаторов. (lowerCamelCase рекомендуется для параметры и переменные ) и является общим соглашением для языков .NET.^[29] Microsoft также рекомендует не использовать подсказки префикса типа (также известные как Венгерская нотация ) используются.^[30] Вместо использования венгерской нотации рекомендуется заканчивать имя именем базового класса; LoginButton вместо BtnLogin.^[31]

Цель-C

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

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

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

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

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

Виртские языки Паскаль, Модула-2 и Оберон обычно используют С заглавной буквы или же Верхняя Верблюд идентификаторы программ, модулей, констант, типов и процедур, а также строчная буква или же lowerCamelCase идентификаторы математических констант, переменных, формальных параметров и функций.^[32] В то время как некоторые диалекты поддерживают символы подчеркивания и доллара в идентификаторах, регистр змейки и регистр макроса, скорее всего, ограничены использованием в интерфейсах внешнего API.^[33]

Perl

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

PHP

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

Python и Ruby

Python и Рубин оба рекомендуют Верхняя Верблюд для имен классов, CAPITALIZED_WITH_UNDERSCORES для констант и lowercase_separated_by_underscores для других имен.

В Python, если имя предназначено для "частный ", он имеет префикс подчеркивания. Частные переменные применяются в Python только по соглашению. Имена также могут быть дополнены суффиксом подчеркивания, чтобы предотвратить конфликт с ключевыми словами Python. Префикс с двойным подчеркиванием изменяет поведение классов в отношении искажение имени. Префикс и суффиксы с двойным подчеркиванием зарезервированы для «магических имен», которые выполняют особое поведение в объектах Python.^[38]

р

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

Раку

Раку следует более или менее тем же соглашениям, что и Perl, за исключением того, что он позволяет использовать инфиксный дефис - или апостроф (или одинарную кавычку) внутри идентификатора (но не двух подряд), при условии, что за ним следует буквенный символ. Поэтому программисты Raku часто используют чехол для шашлыка в их идентификаторах; Например, рыбий корм и не делай этого являются действительными идентификаторами.^[40]

Ржавчина

Ржавчина рекомендует Верхняя Верблюд для псевдонимов типов и имен вариантов struct, trait, enum и enum, КРИК, ЗМЕЯ, ДЕЛО для констант или статики и snake_case для имен переменных, функций и структур.^[41]

Быстрый

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

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

Смотрите также

• Категория: Соглашения об именах
• Checkstyle
• Соглашения о кодировании
• Список инструментов для статического анализа кода
• Пространство имен
• Соглашение об именовании
• Сигил (компьютерное программирование)
• Синтаксис (языки программирования)

Рекомендации

внешняя ссылка

• Американское общество имен - продвигает ономастика, изучение имен и практики именования как в США, так и за рубежом.
• coding-guidelines.com имеет PDF который использует лингвистику и психологию, чтобы попытаться проанализировать затраты / выгоды в вопросах именования идентификаторов