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

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

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

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

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

Потенциальные преимущества

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

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

Проблемы

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

Читабельность

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

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

 a = b * c;

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

 weekly_pay = hours_worked * hourly_pay_rate;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поскольку большинство языков программирования не допускают пробелов в идентификаторах, необходим метод разделения каждого слова (чтобы последующим читателям было легче интерпретировать, какие символы какому слову принадлежат). Исторически некоторые ранние языки, особенно ФОРТРАН (1955 г.) и АЛГОЛ (1958 г.), допускали пробелы внутри идентификаторов, определяя конец идентификаторов по контексту. В более поздних языках от этого отказались из-за сложности токенизации . Можно писать имена, просто объединяя слова, и это иногда используется, например, в mypackage для имен пакетов Java, хотя разборчивость ухудшается при длительном использовании, поэтому обычно используется какая-то форма разделения.

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

Один из подходов заключается в разделении отдельных слов небуквенно-цифровыми символами. Для этой цели обычно используются два символа: дефис ( «-») и подчеркивание («_»); например, имя из двух слов " two words"будет представлено как" two-words" или " two_words".

Дефис используется почти всеми программистами, пишущими на COBOL (1959), Forth (1970) и Lisp (1958); он также распространен в Unix для команд и пакетов и используется в CSS . У этого соглашения нет стандартного имени, хотя его можно называть lisp-case или COBOL-CASE (сравните с Pascal Case ), kebab-case , brochette-case или другими вариантами. Из них кебаб-кейс , датируемый как минимум 2012 годом, с тех пор приобрел некоторую валюту.

Напротив, языки традиции FORTRAN/ALGOL, особенно языки семейств C и Pascal , использовали дефис для оператора вычитания инфиксного и не хотели требовать пробелов вокруг него (как языки свободной формы ), предотвращая его использование в идентификаторы.

Альтернативой является использование подчеркивания; это распространено в семействе C (включая Python), причем слова в нижнем регистре встречаются, например, в «Языке программирования C» (1978) и стали известны как «случай змеи» или «случай улитки» . Символы подчеркивания в верхнем регистре, например UPPER_CASE, обычно используются для макросов препроцессора C , поэтому известных как MACRO_CASE, а также для переменных среды в Unix, таких как BASH_VERSION в bash . Иногда это шутливо называют SCREAMING_SNAKE_CASE (альтернативно SCREAMING_SNAIL_CASE).

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

См. Также: Регистр букв § Стили особого регистра.

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

Примеры форматов идентификаторов, состоящих из нескольких слов

Форматы идентификаторов, состоящих из нескольких слов

Форматирование	Имя(а)
twowords	плоский чемодан
TWOWORDS	ПРОПИСНЫЕ, КРИЧАЩИЕ РЕГИСТРЫ
twoWords	(нижний) CamelCase , dromedaryCase
TwoWords	ПаскальКейс, АпперКэмелКейс
two_words	змеиный_футляр , улиточный_футляр, выбоина_кейс
TWO_WORDS	ALL_CAPS, SCREAMING_SNAKE_CASE , МАКРО_CASE, CONSTANT_CASE
two_Words	верблюд_Snake_Case
Two_Words	Pascal_Snake_Case, Title_Case
two-words	кебаб-кейс , тире-кейс, шепелявый-кейс, спинной футляр
TWO-WORDS	КЕЙС ДЛЯ ПОЕЗДА, КОРПУС КОБОЛ, КЕЙС КРИЧАЩЕГО КЕБАБА
Two-Words	Поезд-кейс, HTTP-заголовок-регистр

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

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

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

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

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

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

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

Схема составных слов (Язык)

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

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

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

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

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

Слова CLASS, обычно расположенные справа (суффикс), служили той же цели, что и префиксы венгерских обозначений .

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

Соглашения, специфичные для языка

ActionScript

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

Есть

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

АПЛ

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

С и С++

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

С#

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

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

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

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

Дарт/Флаттер

В языке Dart , используемом в Flutter SDK , соглашения аналогичны соглашениям Java: за исключением того, что константы написаны в нижнем регистре CamelCase. Dart налагает синтаксическое правило, согласно которому нелокальные идентификаторы начинаются с подчеркивания ( _) рассматриваются как частные (поскольку в языке нет явных ключевых слов для публичного или частного доступа). Кроме того, имена исходных файлов не соответствуют правилу Java «один общедоступный класс для каждого исходного файла, имя должно совпадать». вместо этого используйте Snake_case для имен файлов.

Идти

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

Ява

В Java соглашения об именовании идентификаторов были установлены и предложены различными сообществами Java, такими как Sun Microsystems, Нетскейп, АмбиСофт, и т. д. Ниже приведены примеры соглашений об именах, установленных Sun Microsystems. где имя в « CamelCase » состоит из нескольких слов, соединенных без пробелов, причем начальная буква каждого слова, за исключением первого слова, написана заглавными буквами, например «camelCase».

Тип идентификатора	Правила именования	Примеры
Классы	Имена классов должны быть существительными. UpperCamelCase, с заглавной буквой каждого слова. Используйте целые слова – избегайте аббревиатур и аббревиатур (если только аббревиатура не используется гораздо более широко, чем длинная форма, например URL или HTML).	class Raster {} class ImageSprite {}
Методы	Методы должны быть глаголами lowerCamelCase или имя, состоящее из нескольких слов, которое начинается с глагола в нижнем регистре; то есть первая буква будет строчной, а первые буквы последующих слов — прописными.	run(); runFast(); getBackground();
Переменные	Локальные переменные, переменные экземпляра и переменные класса также записываются на языке lowerCamelCase. Имена переменных не должны начинаться с подчеркивания ( _) или знак доллара ( $) символы, хотя оба разрешены. Это отличается от других соглашений по кодированию , которые гласят, что подчеркивания следует использовать для префикса всех переменных экземпляра. Имена переменных должны быть короткими, но содержательными. Выбор имени переменной должен быть мнемоническим , то есть предназначенным для указания случайному наблюдателю цели ее использования. Следует избегать односимвольных имен переменных, за исключением временных «одноразовых» переменных. Общие имена временных переменных: i, j, k, m и n для целых чисел; c, d и e для символов.	int i; char c; float myWidth;
Константы	Константы следует писать в SCREAMING_SNAKE_CASE . Имена констант также могут содержать цифры, если это необходимо, но не в качестве первого символа.	static final int MAX_PARTICIPANTS = 10;

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

Один широко используемый стиль кодирования Java гласит, что UpperCamelCase использоваться для занятий и lowerCamelCase использоваться для экземпляров и методов . Признавая такое использование, некоторые IDE , такие как Eclipse , реализуют ярлыки на основе CamelCase. Например, в функции помощи по содержимому Eclipse ввод только заглавных букв слова CamelCase будет предлагать любое подходящее имя класса или метода (например, ввод «NPE» и активация помощи по содержимому может предложить NullPointerException).

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

JavaScript

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

Лисп

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

.СЕТЬ

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

Цель-C

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

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

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

В именах методов используются несколько частей нижнего регистра CamelCase, разделенных двоеточиями, разделяющими аргументы, например: application:didFinishLaunchingWithOptions:, stringWithFormat: и isRunning.

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

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

Перл

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

PHP

Рекомендации PHP содержатся в PSR-1 ( Стандартная рекомендация PHP 1) и PSR-12. Согласно PSR-1, имена классов должны быть в PascalCase, константы классов должны быть в MACRO_CASE, а имена функций и методов должны быть в CamelCase.

Питон и Руби

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

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

Р

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

Раку

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

Ржавчина

Руст рекомендует UpperCamelCase для псевдонимов типов и имен структур, черт, перечислений и вариантов перечислений, SCREAMING_SNAKE_CASE для констант или статики и snake_case для имен переменных, функций и членов структуры.

Быстрый

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

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

См. также

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

Внешние ссылки

• На сайте coding-guidelines.com есть PDF-файл , в котором лингвистика и психология используются для анализа затрат и выгод при решении проблем с именованием идентификаторов.