Соглашения об именах (программирование) (Vkilgoyunx kQ nbyug] (hjkijgbbnjkfguny))

Перейти к навигации Перейти к поиску

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

Соглашения, вместо использования произвольных имён, могут применяться для выполнения следующих задач:

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

Выбор соглашений об именах может быть чрезвычайно спорным вопросом, при этом сторонники каждого считают свои соглашения лучшими, а другие — худшими. В просторечии подобные обсуждения называют «холиварами» (от англ. holy war — священная война)[2]. Многие компании устанавливают свои собственные соглашения[3][4][5][6][7][8].

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

[править | править код]

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

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

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

Читаемость

[править | править код]

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

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

a = b * c;

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

weekly_pay = hours_worked * hourly_pay_rate;

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

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

[править | править код]

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

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

[править | править код]

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

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

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

  • более короткие идентификаторы могут быть предпочтительнее как более целесообразные, потому что их легче вводить (хотя многие 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) для точности.

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

[править | править код]
Формат многословных идентификаторов
Формат Имя
twowords flat case[18][19]
TWOWORDS upper flat case[18]
twoWords (lower) camelCase, dromedaryCase
TwoWords (upper) CamelCase, PascalCase, StudlyCase[20]
two_words snake case, pothole_case
TWO_WORDS SCREAMING SNAKE CASE, MACRO_CASE, CONSTANT_CASE
Two_Words Camel_Snake_Case[21]
two-words kebab-case, dash-case, lisp-case
TWO-WORDS TRAIN-CASE, COBOL-CASE, SCREAMING-KEBAB-CASE
Two-Words Train-Case,[18] HTTP-Header-Case[21]

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

[править | править код]

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

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

[править | править код]

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

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

[править | править код]

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

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

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

[править | править код]

«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 (флаг) будет указывать на поле только с двумя возможными значениями.

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

[править | править код]

ActionScript

[править | править код]

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

Ada

[править | править код]

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

APL

[править | править код]

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

C и C++

[править | править код]

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

C#

[править | править код]

Соглашения об именах 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

[править | править код]

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

Java

[править | править код]

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

Тип идентификатора Правила именования Примеры
Классы Имена классов должны быть существительными в Upper CamelCase, первая буква каждого слова должна быть заглавной. Используйте целые слова — избегайте акронимов и сокращений (если только аббревиатура не используется гораздо шире, чем длинная форма, например URL или HTML).
  • class Raster {}
  • class ImageSprite {}
Методы Методы должны быть глаголами в lower CamelCase регистре lower CamelCase или названиями из нескольких слов, которые начинаются с глагола в нижнем регистре; то есть, первая буква в нижнем регистре и первые буквы последующих слов в верхнем регистре.
  • run();
  • runFast();
  • getBackground();
Переменные Локальные переменные, переменные экземпляра и переменные класса также записываются в lower CamelCase. Имена переменных не должны начинаться с символа подчёркивания (_) или знака доллара ($), даже если и то и другое разрешено. Это контрастирует с другими соглашениями о кодировании, которые гласят, что для префиксов всех переменных экземпляра следует использовать подчёркивания.

Имена переменных должны быть короткими, но содержательными. Выбор имени переменной должен быть мнемоническим, то есть, предназначенным для указания случайному наблюдателю цели его использования. Следует избегать односимвольных имён переменных, за исключением временных «одноразовых» переменных. Общие имена временных переменных: 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 — для экземпляров и методов[29]. Признавая такое использование, некоторые IDE, такие как Eclipse, реализуют ярлыки на основе CamelCase. Например, в функции поддержки содержимого Eclipse ввод только заглавных букв слова CamelCase будет предлагать любое подходящее имя класса или метода (например, ввод «NPE» и активация помощника по содержимому может предложить NullPointerException).

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

JavaScript

[править | править код]

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

Lisp

[править | править код]

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

.NET

[править | править код]

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

Objective-C

[править | править код]

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

[править | править код]

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

Perl

[править | править код]

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

PHP

[править | править код]

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

Python и Ruby

[править | править код]

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

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

R

[править | править код]

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

Raku

[править | править код]

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

Rust

[править | править код]

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

Swift

[править | править код]

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

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

См. также

[править | править код]

Примечания

[править | править код]
  1. ↑ Derek M. Jones «Operand names influence operator precedence decisions» Архивная копия от 6 сентября 2021 на Wayback Machine An experiment investigating the effect of variable names on operator precedence selection
  2. ↑ Какие стили оформления кода предпочитает аудитория Гитхаба? — «В самом популярном холиваре „пробелы против табуляции“ решительную победу одержали пробелы.»
  3. ↑ Google Style Guides (англ.). Дата обращения: 22 сентября 2021. Архивировано 19 октября 2021 года.
  4. ↑ Facebook. HHVM Coding Conventions (англ.). Дата обращения: 22 сентября 2021. Архивировано 11 ноября 2020 года.
  5. ↑ Oracle. Code Conventions for the Java TM Programming Language (англ.). Дата обращения: 22 сентября 2021. Архивировано 22 июня 2010 года.
  6. ↑ Steven Hughes, Linda Jun, Wendy Shoan. C++ Coding Standards and Style Guide (англ.). NASA (24 мая 2005). Дата обращения: 22 сентября 2021. Архивировано 21 апреля 2021 года.
  7. ↑ JetBrains. Coding conventions (англ.). Kotlin. Дата обращения: 22 сентября 2021. Архивировано 28 сентября 2021 года.
  8. ↑ Airbnb JavaScript Style Guide (англ.). Дата обращения: 22 сентября 2021. Архивировано 23 сентября 2021 года.
  9. ↑ Naming a Package. Дата обращения: 9 ноября 2020. Архивировано 6 ноября 2020 года.
  10. ↑ CSS reference. Mozilla Developer Network. Дата обращения: 18 июня 2016. Архивировано 13 января 2021 года.
  11. ↑ StackOverflow – What's the name for snake_case with dashes? Дата обращения: 9 ноября 2020. Архивировано 26 декабря 2014 года.
  12. ↑ Programmers – If this is camelCase what-is-this? Дата обращения: 9 ноября 2020. Архивировано из оригинала 7 августа 2016 года.
  13. ↑ Camel_SNAKE-kebab (сентябрь 2019). Дата обращения: 9 ноября 2020. Архивировано 11 июня 2018 года.
  14. ↑ UnderscoreVersusCapitalAndLowerCaseVariableNaming
  15. ↑ jwfearn. Revisions to jwfearn's answer to What's the name for dash-separated case? (5 сентября 2012). Дата обращения: 9 ноября 2020. Архивировано 10 мая 2017 года.
  16. ↑ Living Clojure (2015), by Carin Meier, p. 91 Архивная копия от 19 сентября 2020 на Wayback Machine
  17. ↑ lodash: kebabCase. Дата обращения: 9 ноября 2020. Архивировано 8 января 2021 года.
  18. ↑ 1 2 3 naming - What are the different kinds of cases? Stack Overflow. Дата обращения: 16 августа 2020. Архивировано 17 июня 2020 года.
  19. ↑ A brief list of programming naming conventions (брит. англ.). deanpugh.com (20 марта 2018). Дата обращения: 16 августа 2020. Архивировано 10 августа 2020 года.
  20. ↑ PSR-1: Basic Coding Standard - PHP-FIG (англ.). www.php-fig.org. Дата обращения: 4 сентября 2020. Архивировано 31 марта 2019 года.
  21. ↑ 1 2 camel-snake-kebab (амер. англ.). camel-snake-kebab. Дата обращения: 16 августа 2020. Архивировано 11 августа 2020 года.
  22. ↑ Making Wrong Code Look Wrong (11 мая 2005). Дата обращения: 9 ноября 2020. Архивировано 22 ноября 2016 года.
  23. ↑ 3.2.1 Names — Chapter 3 — Ada 95 QUALITY AND STYLE Guide. Дата обращения: 9 ноября 2020. Архивировано 29 июня 2020 года.
  24. ↑ ISO/IEC 9899:1999 Programming languages – C. ISO. Дата обращения: 9 ноября 2020. Архивировано 29 января 2017 года.
  25. ↑ ISO/IEC 14882:2011 Information technology – Programming languages – C++. ISO. Дата обращения: 9 ноября 2020. Архивировано 17 мая 2013 года.
  26. ↑ Naming Guidelines. Microsoft. Дата обращения: 9 ноября 2020. Архивировано 17 ноября 2020 года.
  27. ↑ Names of Type Members. Microsoft. Дата обращения: 9 ноября 2020. Архивировано 14 ноября 2020 года.
  28. ↑ Effective Go - the Go Programming Language. Дата обращения: 9 ноября 2020. Архивировано 6 января 2015 года.
  29. ↑ 1 2 «Code Conventions for the Java Programming Language», Section 9: «Naming Conventions» Архивная копия от 27 февраля 2009 на Wayback Machine
  30. ↑ «Netscape’s software coding ctandards guide for Java», Collab Software Coding Standards Guide for Java Архивировано 3 марта 2009 года.
  31. ↑ «AmbySoft Inc. Coding Standards for Java v17.01d». Дата обращения: 9 ноября 2020. Архивировано 20 августа 2020 года.
  32. ↑ Morelli. 5 JavaScript Style Guides – Including AirBnB, GitHub, & Google. codeburst.io (17 ноября 2017). Дата обращения: 17 августа 2018. Архивировано 12 ноября 2017 года.
  33. ↑ Конвенции Дугласа Крокфорда. Дата обращения: 9 ноября 2020. Архивировано 4 октября 2020 года.
  34. ↑ Variables. Дата обращения: 9 ноября 2020. Архивировано 11 ноября 2020 года.
  35. ↑ Naming conventions Архивная копия от 30 октября 2020 на Wayback Machine on CLiki
  36. ↑ Microsoft .NET Framework Capitalization Styles. Дата обращения: 9 ноября 2020. Архивировано 24 марта 2017 года.
  37. ↑ .NET Framework Developer’s Guide — General Naming Conventions. Дата обращения: 9 ноября 2020. Архивировано 3 марта 2016 года.
  38. ↑ Framework Design Guidelines, Krzysztof Cwalina, Brad Abrams Page 62
  39. ↑ Modula-2 Name Convention. Дата обращения: 9 ноября 2020. Архивировано из оригинала 10 сентября 2016 года.
  40. ↑ Foreign API Identifiers in Modula-2 Name Convention. Дата обращения: 9 ноября 2020. Архивировано из оригинала 10 сентября 2016 года.
  41. ↑ Perl style guide. Дата обращения: 9 ноября 2020. Архивировано 26 июня 2013 года.
  42. ↑ perlmodlib – constructing new Perl modules and finding existing ones. Дата обращения: 9 ноября 2020. Архивировано 28 июня 2020 года.
  43. ↑ PHP standards recommendations. Дата обращения: 9 ноября 2020. Архивировано 12 ноября 2020 года.
  44. ↑ PSR-1: Basic Coding Standard — PHP-FIG. Дата обращения: 9 ноября 2020. Архивировано 31 марта 2019 года.
  45. ↑ Style Guide for Python Code PEP8. Дата обращения: 9 ноября 2020. Архивировано 13 июля 2018 года.
  46. ↑ Style Guide for RCode. Дата обращения: 9 ноября 2020. Архивировано 14 ноября 2020 года.
  47. ↑ General rules of Perl 6 syntax. Дата обращения: 9 ноября 2020. Архивировано 22 июля 2019 года.
  48. ↑ Naming conventions (англ.). doc.rust-lang.org. Дата обращения: 4 февраля 2018. Архивировано 4 февраля 2018 года.
  49. ↑ swift.org API Design Guidelines. Дата обращения: 9 ноября 2020. Архивировано 12 января 2021 года.

Ссылки

[править | править код]
Источник — https://ru.wikipedia.org/w/index.php?title=Соглашения_об_именах_(программирование)&oldid=140209138