Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

Возможные преимущества [ править ]

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

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

Проблемы [ править ]

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

Читаемость [ править ]

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

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

 а  =  Ь  *  с ;

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

 weekly_pay  =  часы_работано  *  почасовая_плата ;

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

Эксперименты показывают, что стиль идентификатора влияет на отзыв и точность, а знакомство со стилем ускоряет отзыв. [3]

Общие элементы [ править ]

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

Длина идентификаторов [ править ]

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

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

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

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

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

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

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

Регистр букв и цифры [ править ]

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

Многословные идентификаторы [ править ]

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

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

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

Один из подходов - разделить отдельные слова не буквенно-цифровыми символами. Для этой цели обычно используются два символа: дефис («-») и подчеркивание («_»); например, имя из двух слов two wordsбудет представлено как " two-words" или " two_words". Дефис используется почти всеми программистами, пишущими COBOL (1959), Forth (1970) и Lisp (1958); он также распространен в Unix для команд и пакетов и используется в CSS . [5] У этого соглашения нет стандартного названия,хотя он может называться lisp-case или COBOL-CASE(сравни Паскаль случай ), кебаб случай , Шашлык случай , или другие варианты. [6] [7] [8] [9] Из них кебаб-футляр , датируемый по крайней мере 2012 годом, [10] с тех пор приобрел некоторую ценность. [11] [12]

Напротив, языки в традиции 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плоский футляр [13] [14]
TWOWORDSверхний плоский корпус [13]
twoWords(нижний) футляр для верблюда, футляр для верблюда
TwoWordsPascalCase, UpperCamelCase, StudlyCase [15]
two_wordssnake_case , pothole_case
TWO_WORDSSCREAMING_SNAKE_CASE , MACRO_CASE, CONSTANT_CASE
two_Wordsверблюд, змея, футляр
Two_WordsПаскаль, змея, футляр
two-wordsкебаб-кейс , тире-кейс, лисп-кейс
two|wordsдонер | дело
TWO-WORDSПОЕЗД-ДЕЛО, COBOL-CASE, SCREAMING-KEBAB-CASE
Two-WordsОбучающий регистр, [13] HTTP-заголовок-регистр [16]

Метаданные и гибридные соглашения [ править ]

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

Венгерская нотация [ править ]

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

Позиционное обозначение [ править ]

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

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

Составная схема слов (OF Language) [ править ]

«Язык OF» IBM был задокументирован в руководстве по 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 . [ необходима цитата ] Стиль идентификаторов похож на стиль Java .

Ада [ править ]

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

APL [ править ]

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

C и C ++ [ править ]

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

C # [ править ]

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

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

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

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

Перейти [ править ]

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

Java [ править ]

В Java соглашения об именах для идентификаторов были установлены и предложены различными сообществами Java, такими как Sun Microsystems, [24] Netscape, [25] AmbySoft, [26] и т. Д. Ниже приведены примеры соглашений об именах, установленных Sun Microsystems, где имя в « CamelCase » - это имя, составленное из нескольких слов, соединенных без пробелов, причем каждое слово - за исключением первого слова - начальная буква заглавными буквами, например «camelCase».

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

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

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

JavaScript [ править ]

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

Лисп [ править ]

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

.NET [ править ]

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

Objective-C [ править ]

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

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

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

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

Паскаль, Модула-2 и Оберон [ править ]

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

Perl [ править ]

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

PHP [ править ]

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

Python и Ruby [ править ]

И Python, и Ruby рекомендуют UpperCamelCaseиспользовать имена классов, CAPITALIZED_WITH_UNDERSCORESконстанты и lowercase_separated_by_underscoresдругие имена.

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

R [ править ]

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

Раку [ править ]

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

Ржавчина [ править ]

Rust рекомендует UpperCamelCaseиспользовать псевдонимы типов и имена вариантов структур, признаков, перечислений и перечислений, SCREAMING_SNAKE_CASEконстанты или статики snake_case, а также имена переменных, функций и членов структуры. [42]

Swift [ править ]

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

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

См. Также [ править ]

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

Ссылки [ править ]

  1. ^ Дерек М. Джонс «Имена операндов влияют на решения о приоритете операторов» . Эксперимент, исследующий влияние имен переменных на выбор приоритета операторов.
  2. Перейти ↑ Raymond, Eric S. (1 октября 2004 г.). «религиозные вопросы» . Жаргон файл (версия 4.4.8 ред.) . Проверено 7 ноября 2011 года .
  3. ^ Бинкли, Дэйв; Дэвис, Марсия (2009). «В CamelCase или Under_score» (PDF) . 17-я Международная конференция IEEE 2009 г. по пониманию программ (17): 158–167. DOI : 10.1109 / ICPC.2009.5090039 .
  4. ^ Присвоение имени пакету
  5. ^ "Справочник по CSS" . Сеть разработчиков Mozilla . Проверено 18 июня +2016 .
  6. ^ "StackOverflow - Как называется snake_case с тире?" .
  7. ^ "Программисты - Если это CamelCase, что это?" .
  8. ^ "Camel_SNAKE-kebab" . Сентябрь 2019 г.
  9. ^ ПодчеркиваниеVersusCapitalAndLowerCaseVariableNaming
  10. ^ jwfearn (5 сентября 2012 г.). "Изменения в ответе jwfearn на вопрос Как называется регистр, разделенный тире?" .
  11. ^ Living Clojure (2015), Карин Мейер, стр. 91
  12. ^ lodash: kebabCase
  13. ^ a b c "именование - Какие бывают случаи?" . Переполнение стека . Дата обращения 16 августа 2020 .
  14. ^ «Краткий список соглашений об именах программирования» . deanpugh.com . 20 марта 2018 . Дата обращения 16 августа 2020 .
  15. ^ «PSR-1: Базовый стандарт кодирования - PHP-FIG» . www.php-fig.org . Дата обращения 4 сентября 2020 .
  16. ^ "верблюжья змея-шашлык" . верблюжья-змея-шашлык . Дата обращения 16 августа 2020 .
  17. ^ "Сделать неправильный код неправильным" . 11 мая 2005 г.
  18. ^ http://www.adaic.org/resources/add_content/docs/95style/html/sec_3/3-2-1.html
  19. ^ "ISO / IEC 9899: 1999 Языки программирования - C" . ISO.
  20. ^ «ISO / IEC 14882: 2011 Информационные технологии - Языки программирования - C ++» . ISO.
  21. ^ «Правила присвоения имен» . Microsoft.
  22. ^ «Имена членов типа» . Microsoft.
  23. ^ «Эффективный Go - язык программирования Go» .
  24. ^ a b «Соглашения о кодах для языка программирования Java», Раздел 9: «Соглашения об именах»
  25. ^ "РУКОВОДСТВО ПО СТАНДАРТАМ КОДИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ NETSCAPE ДЛЯ JAVA", Руководство по стандартам кодирования программного обеспечения Collab для Java. Архивировано 3 марта 2009 г. на Wayback Machine.
  26. ^ "Стандарты кодирования AmbySoft Inc. для Java v17.01d"
  27. Рианна Морелли, Брэндон (17 ноября 2017 г.). «5 руководств по стилю JavaScript, включая AirBnB, GitHub и Google» . codeburst.io . Проверено 17 августа 2018 года .
  28. ^ "Переменные" .
  29. ^ Соглашения об именах в CLiki
  30. ^ Стили заглавных букв Microsoft .NET Framework
  31. ^ Руководство разработчика .NET Framework - Общие соглашения об именах
  32. ^ [Рекомендации по разработке каркаса, Кшиштоф Квалина, Брэд Абрамс, стр. 62]
  33. ^ Соглашение об именах Modula-2
  34. ^ Идентификаторы внешних API в соглашении об именах Modula-2
  35. ^ "Руководство по стилям Perl" .
  36. ^ "perlmodlib - создание новых модулей Perl и поиск существующих" .
  37. ^ "Рекомендации стандартов PHP" .
  38. ^ https://www.php-fig.org/psr/psr-1/
  39. ^ Руководство по стилю для кода Python PEP8
  40. ^ Руководство по стилю для RCode
  41. ^ «Общие правила синтаксиса Perl 6» .
  42. ^ «Соглашения об именах» . doc.rust-lang.org . Проверено 4 февраля 2018 года .
  43. ^ "Рекомендации по проектированию API swift.org" .

Внешние ссылки [ править ]

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