В программировании соглаше́ние об имена́х — набор правил именования идентификаторов, обозначающих переменные, типы, функции и другие вещи в исходном коде и документации.
Соглашения, вместо использования произвольных имён, могут применяться для выполнения следующих задач: чтобы упростить чтение и понимание исходного кодаDerek M. Jones «Operand names influence operator precedence decisions» An experiment investigating the effect of variable names on operator precedence selection; чтобы при чтении кода можно было сосредоточиться на более важных вопросах, чем споры о наименованиях; чтобы инструменты проверки качества кода могли сосредоточить свои отчёты на важных проблемах вместо стандартов оформления кода.
Выбор соглашений об именах может быть чрезвычайно спорным вопросом, при этом сторонники каждого считают свои соглашения лучшими, а другие — худшими. В просторечии подобные обсуждения называют «холиварами» (от — священная война). Многие компании устанавливают свои собственные соглашения.
Потенциальные выгоды Некоторые из потенциальных преимуществ, которые можно получить, приняв соглашение об именах: предоставление дополнительной информации (метаданных) об использовании идентификатора; формализация ожиданий, устранение противоречий в работе команды разработчиков; обеспечение возможности использования автоматизированного рефакторинга или инструментов поиска и замены с минимальной вероятностью ошибки; повышение ясности в случае возможной двусмысленности; улучшение эстетического и профессионального внешнего вида кода (например, путём запрета слишком длинных имён, смешных или «симпатичных» имён или сокращений); предотвращение «конфликтов имён», которые могут возникнуть при объединении кода разных команд (см. также: пространства имён); предоставление значимых данных при передаче проекта другой команде; улучшение понимания при повторном использовании кода через длительный промежуток времени.
Выбор соглашений об именах (и степени их соблюдения) часто является спорным вопросом, поскольку сторонники придерживаются своей точки зрения как лучшей, а другие — как худшей. Более того, даже при наличии известных и чётко определённых соглашений об именах некоторые организации могут не соблюдать их постоянно, что приводит к несогласованности и путанице. Эти проблемы могут усугубляться, если правила соглашения об именах внутренне непоследовательны, произвольны, трудны для запоминания или иным образом воспринимаются как более обременительные, чем полезные.
Читаемость Правильно подобранные идентификаторы значительно упрощают разработчикам и аналитикам понимание того, что делает система, и как исправить или расширить исходный код, чтобы применить его для новых нужд.
Например, хотя 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, хотя разборчивость страдает от более длинных терминов, поэтому обычно используется какая-то форма разделения.
Слова, разделённые разделителями Один из подходов — разделить отдельные слова не буквенно-цифровыми символами. Для этой цели обычно используются два символа: дефис («-») и подчёркивание («_»); например, имя из двух слов «two words» будет представлено как «two-words» или «two_words». Дефис используется почти всеми программистами, пишущими на COBOL (1959), Forth (1970) и Lisp (1958); он также распространён в Unix для команд и пакетов и используется в CSS. У этого соглашения нет стандартного названия, хотя оно может называться lisp-case или COBOL-CASE (сравните Pascal case), kebab-case, brochette-case или другими вариантамиUnderscoreVersusCapitalAndLowerCaseVariableNaming. Из них кебаб-регистр, датируемый по крайней мере 2012 годом, с тех пор стал популярнымLiving Clojure (2015), by Carin Meier, p. 91 .
Напротив, языки в традиции 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) для точности.
Примеры форматов многословных идентификаторов +Формат многословных идентификаторовФорматИмяtwowordsflat caseTWOWORDSupper flat casetwoWords(lower) camelCase, dromedaryCaseTwoWords(upper) CamelCase, PascalCase, StudlyCasetwo_wordssnake case, pothole_caseTWO_WORDSSCREAMING SNAKE CASE, MACRO_CASE, CONSTANT_CASETwo_WordsCamel_Snake_Casetwo-wordskebab-case, dash-case, lisp-caseTWO-WORDSTRAIN-CASE, COBOL-CASE, SCREAMING-KEBAB-CASETwo-WordsTrain-Case, HTTP-Header-Case
Метаданные и гибридные соглашения Некоторые соглашения об именах представляют собой правила или требования, которые выходят за рамки требований конкретного проекта или предметной области, а вместо этого отражают более широкий комплекс принципов, определённых архитектурой программного обеспечения, базовым языком программирования или другой методологией кросс-проекта.
Венгерская нотация Возможно, наиболее известной является венгерская нотация, которая кодирует либо назначение («Apps Hungarian»), либо тип («Systems Hungarian») переменной в её имени. Например, префикс «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 (флаг) будет указывать на поле только с двумя возможными значениями.