camelCase против under_score
В настоящее время существует много стандартов наименования переменных, но два из них являются наиболее популярными среди программистов: это camel case («Верблюжья» нотация) и underscore (именование переменных с использованием символа нижнего подчеркивания в качестве разделителя). Кто-то может возразить, что существуют и другие популярные стандарты, но в рамках данной статьи мы сравним эти два, и узнаем у программистов — какого стандарта придерживаются они. Конечно, некоторые программисты связаны рамками стандартов кодирования языка или фреймворка, который они используют, но мы постараемся сделать независимое сравнение.
Стандарт наименований с использованием нижнего подчеркивания заключается в том, что все слова записываются строчными буквами и разделяются символом нижнего подчеркивания (_). Обычно этот стандарт используется в названиях функций и переменных, а для названий классов, структур, интерфейсов используется стандарт Pascal (прим. переводчика: почему-то в статье про него ничего не говорится, но как я нашел в википедии Pascal style это UpperCamelCase, когда первое слово начинается с прописной буквы, пруф). Underscore изначально использовался программистами С, и потом был использован разработчиками С++ при наименовании ключевых слов и в библиотеке STL, а затем и в Boost, из-за чего данный стандарт приобрел большую популярность среди программистов С++, но не стал доминирующим. Также данный стандарт используется в названиях стандартных функций PHP, и является очень популярным среди PHP-программистов. Говорят, что в Руби тоже используется нижнее подчеркивание.
С другой стороны, верблюжья нотация является стандартом в языке Java и его младшей сестре JavaScript, хотя ее можно встретить также и в других местах. Согласно этому стандарту, все слова в названии начинаются с прописной буквы, кроме первого. При этом, естественно, не используется никаких разделителей вроде нижнего подчеркивания. Обычно данный стандарт применяют к именам функций и переменных, при этом в именах классов (структур, интерфейсов) используется стандарт Pascal. В языке С# camelCase используется частично: область его применения ограничена названиями параметров функций и локальными переменными.
От переводчика: статью старался переводить максимально близко к оригиналу.
От себя добавлю, что в своих проектах предпочитаю использовать Camel Case, только в качестве первого слова использую сокращенный тип переменной (bProductActive, iProductsCount, sUserName), таким образом несколько решается проблема «взрыва мозга» — все слова предложения начинаются с заглавной буквы.
Кроме того, с коллегами очень много споров было на тему аббревиатур при использовании верблюжьей нотации: как писать правильнее GenerateHTMLFromText или GenerateHtmlFromText, в итоге остановились на втором варианте, но чувство нерешенной проблемы все равно немного грызет.
Ну и насчет того, что JavaScript это младшая сестра Java автор немного нагнал, все-таки это совершенно разные языки, общее у них только название и стандарты оформления кода.
Стили написания составных слов в программировании
Перевод статьи Чейза Адамса «Most Common Programming Case Types».
Работая с компьютерами и, в особенности, занимаясь программированием, вы неизбежно столкнетесь с необходимостью давать названия чему-либо. Это одно из двух самых сложных дел в информатике.
Чтобы именование было успешным, самое главное – определиться со стилем написания составных слов. Это важно для поддержания последовательности в пределах одного проекта или рабочего пространства. Если вы занимаетесь созданием программного обеспечения, то в спецификации своего языка вы можете встретить указание на определенный стиль. Некоторые языки (в частности, Go) очень полагаются на ваше знание разницы между стилями и правильное их использование.
Прочитав эту статью, вы узнаете:
Самые распространенные стили написания составных слов:
Как их использовать в следующих ситуациях:
camelCase
camelCase должен начинаться со строчной буквы, а первая буква каждого последующего слова должна быть заглавной. Все слова при этом пишутся слитно между собой.
Пример camelCase для имени переменной camel case var – camelCaseVar.
snake_case
Чтобы писать в стиле snake_case, нужно просто заменить пробелы знаками подчеркивания. Все слова при этом пишутся строчными буквами. Можно использовать snake_case, смешивая его с camelCase и PascalCase, но, как по мне, при этом теряется сам смысл этого стиля.
Пример snake_case для имени переменной snake case var – snake_case_var.
kebab-case
kebab-case похож на snake_case, только в нем пробелы заменяются на дефисы. Слова также пишутся строчными буквами. Опять же, его можно смешивать с camelCase и PascalCase, но в этом нет смысла.
Пример kebab-case для переменной kebab case var – kebab-case-var.
PascalCase
В PascalCase каждое слово начинается с заглавной буквы (в отличие от camelCase, где первое слово начинается со строчной).
Пример PascalCase для переменной pascal case var – PascalCaseVar.
Примечание: этот стиль часто путают с camelCase, но это, тем не менее, отдельный стиль.
UPPER_CASE_SNAKE_CASE
В UPPER_CASE_SNAKE_CASE все слова пишутся заглавными буквами, а пробелы заменяются знаками подчеркивания.
Пример UPPER_CASE_SNAKE_CASE для переменной upper case snake case var – UPPER_CASE_SNAKE_CASE_VAR.
Как выбрать стиль написания составных слов?
Теперь, когда вы ознакомились с различными стилями, давайте рассмотрим примеры их использования для выбора названий файлов и для программирования на разных языках. Я буду указывать вариант, который, как мне кажется, является лучшим подходом.
Какого соглашения придерживаться, выбирая имена для файлов?
Совет: всегда snake_case
При выборе названий для файлов важно задавать вопрос: «Каков наименьший общий знаменатель?». Если у вас нет собственного мнения на этот счет, поделюсь своим опытом. Лучший результат у меня всегда получался при использовании snake_case. В этом случае название файла сохраняет читабельность и при этом вряд ли приведет к каким-либо проблемам в файловой системе.
Если вы пользуетесь Mac или работаете с пользователями Mac, будет хорошей идеей всегда использовать только строчные буквы. Файловая система Mac – HFS+, а поскольку она нечувствительна к регистру, то файлы «MyFile» и «myfile» не будут различаться.
Мой главный аргумент в пользу этого подхода связан с особенно коварным «багом», который я видел при запуске CI/CD (непрерывной интеграции/непрерывной доставки) кластера. Во время сборки проекта на React в работе CI возник сбой с сообщением «файл не найден: mycomponent.js». Разработчик божился, что этот файл был в исходниках проекта.
Я обнаружил, что они импортировали «mycomponenet.js», но файл назывался «MyComponent.js». Это ведь был проект на React, где для наименований компонентов файлов используется именно PascalCase. Поскольку HFS+ не различает регистры, файл «MyComponent.js» был успешно принят за «mycomponent.js», когда разработчик писал код (на Mac). Но когда выполнялась сборка на сервере CI (а он был на основе Unix), возник сбой, потому что система искала точное соответствие названия.
Соглашения Go
В Go критически важно быть внимательным к соглашениям о наименованиях. Этот язык определяет доступность переменной, поля или метода для вызова исходя из того, со строчной или заглавной буквы начинается имя.
type ExportedStruct <
unexportedField string
>[/code]
В этом примере ExportedStruct доступен для пакетных вызовов для casetypes, а unexportedField доступен только для методов ExportedStruct.
Соглашения JavaScript
Соглашения React
У меня довольно большой опыт программирования на React, к тому же он довольно уникален, поэтому заслуживает своего подраздела:
Соглашения Ruby
Соглашения Python
Другие соглашения
Таблица для быстрого сравнения
| Стиль написания | Пример |
| Исходное написание имени переменной | some awesome var |
| Camel Case | someAwesomeVar |
| Snake Case | some_awesome_var |
| Kebab Case | some-awesome-var |
| Pascal Case | SomeAwesomeVar |
| Upper Case Snake Case | SOME_AWESOME_VAR |
Теперь, зная самые распространенные стили написания, вам будет легче определиться, какой использовать при написании своего кода!
Нотации в программировании: верблюд, змея, шашлык и другие
Пять способов соединить слова в одно длинное название — с вариациями и пояснениями.
Часто для хорошего имени переменной или метода программистам не хватает одного слова. Например, название метода calculate, конечно, намекает на то, что в нём что-то вычисляется, но что конкретно — непонятно, нужны ещё слова.
Проблема с языками программирования в том, что пробелы в названиях там недопустимы — нельзя назвать метод calculate elephant weight. Поэтому появились многочисленные варианты соединения слов с помощью изменения регистра букв или дописывания символов-разделителей.
Соглашения об именовании переменных, констант и других идентификаторов в программном коде называют нотациями.
Расскажем, какие нотации существуют и для чего они используются.
Фулстек-разработчик. Любимый стек: Java + Angular, но в хорошей компании готова писать хоть на языке Ада.
Верблюжья нотация (сamel case, camelCase)
Первое слово пишется со строчной буквы, следующие — с заглавной, разделителей между составными частями нет. Торчащие посреди итогового названия заглавные буквы напомнили кому-то горбы верблюда — так возникло название нотации.
Используется во многих языках программирования для именования переменных, функций, методов — например, в Java, JavaScript, PHP. В языке Go в camelCase объявляют внутренние поля и методы.
Язык Go вообще чувствителен к именам: от того, с какой буквы, строчной или заглавной, начинается имя переменной, зависит её область видимости — то, какие другие компоненты приложения смогут к этой переменной обратиться.
Для внутренних переменных подходит camelCase, а для публичных (экспортируемых) обязательно делать первую букву названия заглавной, то есть именовать в стиле PascalCase.
Нотация Паскаля (Pascal case, PascalCase)
Тот же camelCase, но все слова, даже первое, начинаются с заглавной буквы.
Стиль так называется вовсе не в честь Блеза Паскаля. Pascal case стал известным благодаря одному почти забытому языку Паскаль — в нём так именовались переменные, процедуры и функции.
А вот язык Паскаль, кстати, назван Никлаусом Виртом, его создателем, как раз в честь великого француза.
Иногда Pascal case называют upper camel case или, наоборот, camel case называют low Pascal case.
В XIX веке программирования ещё не было, зато уже были химия и химики. Один из них, некто Берцелиус, предложил в формулах веществ называть химические элементы одной или двумя буквами, а итог записывать в одно слово без пробелов. Причём первые буквы составляющих должны быть заглавными.
Благодаря этому прекрасному человеку мы до сих пор записываем формулу поваренной соли в виде NaCl, а не целиком Sodium Chloride или менее читабельно — NA CL.
Змеиная нотация (snake case, snake-case)
Слова разделяются символами подчёркивания — они как бы ползут по строке, в результате получается длииинное, как змея, название.
Используется, например, в языках Python и Rust для имён переменных и функций.
Если в предыдущем примере заменить все буквы на заглавные, то получится SCREAMING_SNAKE_CASE (кричащая змеиная нотация).
Эту вариацию чаще всего применяют для определения констант — в тех же Python и Rust, Java, PHP и многих других.
Кричащей её назвали, потому что в интернет-переписке переход на капс часто означает повышение градуса беседы и даже крик.
Исследование Бониты Шариф и её коллег по Кентскому университету показало, что имена, разделённые подчёркиваниями, быстрее распознаются. Чтобы это доказать, учёные записывали движения глаз участников эксперимента, пока те читали названия в разных нотациях.
Шашлычная нотация (kebab case, kebab-case)
В этой нотации слова разделяют символом дефиса. При некоторой доле фантазии можно представить, что слова при этом как бы насаживают на шампур — вот и получается шашлык (kebab).
Примеры использования мы каждый день видим в URL-адресах, ещё kebab-имена дают CSS-стилям и HTML-тегам. В стайлгайде для Angular (фреймворк для веб-разработки) в kebab-нотации рекомендуют называть файлы компонентов, сервисов и других элементов приложения.
Существует kebab-case со всеми заглавными буквами — это SCREAMING-KEBAB-CASE (кричащая шашлычная нотация). Второе название такого стиля — COBOL_CASE, потому что в нём записывают все названия в языке COBOL. Это старый, но очень живучий язык.
Проблема с этой нотацией в том, что знак дефиса можно интерпретировать как минус. Так что, если поставить этот разделитель не там, можно получить весёлые и странные баги.
Плоская нотация (flat case, flatcase)
Чтобы получить наименование в этом стиле, нужно просто записать слова рядом без пробелов, все буквы каждого слова должны быть строчными.
Переменные, классы и другие элементы программ обычно так не называют — их будет сложно разделить на слова при чтении, особенно если слов больше двух, как в примере. Зато плоская нотация встречается в именах пакетов. В Java, например, можно создать пакет com.example.flatcase.mypackage.
Но чаще всего такого рода длинные надписи мы видим в соцсетях — #этожеобычнаяпрактикадлятегов 🙂
Как выбрать нотацию
Лучшей нотации на все случаи жизни не существует. Для разных языков программирования есть разные соглашения о наименованиях — это свод правил с рекомендациями, какие имена стоит выбирать для разных элементов программы (переменных, классов, методов и тому подобного). Например, здесь такого рода соглашения для Python, а здесь — для Java.
Обычно разработчики придерживаются этих общепринятых рекомендаций, но никто не запрещает IT-компаниям устанавливать свои правила, если они не противоречат синтаксису языка. В таком случае лучше соблюдать местные соглашения — если, конечно, вы хотите задержаться в этой компании 🙂
Мы на наших курсах не своевольничаем — учим называть переменные по всем канонам языка: будь то Java, C#, популярный сейчас R или другие из нашего каталога курсов. Бонусом к правилам наименования — навыки программирования на выбранном языке, а потом и помощь в трудоустройстве.
обложка: Анастасия Телесницкая для Skillbox Media
Верблюжья нотация или нижние подчёркивания: научный подход
Авторизуйтесь
Верблюжья нотация или нижние подчёркивания: научный подход
Если по странному стечению обстоятельств вы программист, который не беспокоится, использовать ли верблюжий регистр или нижние подчёркивания для обозначения переменных, то пришло время определиться. Постарайтесь выбрать независимо от соглашений по оформлению кода, привычки или типа идентификатора. Если вы пишите на Lisp и любите тире, просто проголосуйте за вариант, который вам больше понравился.
Проголосовали? Отлично! Теперь моя очередь провести некоторую работу и попытаться дать вам полу-научное обоснование того, какой стиль форматирования лучше всего подходит для программирования.
Честно говоря, такой код проще читать.
Я бы не написал этот пост, если бы не прочитал статью Коена «Tao of Coding». Как мой бывший коллега, он переманил меня на сторону нижнего подчёркивания. Толчком к финальному решению послужил ответ в одном из споров по поводу соглашений об именовании. Он дан в цитате слева. Так что же, это просто мнение или действительно факт?
Это вдохновило меня обратиться к научным источникам. Ведь должны были проводить какие-то исследования в этой области? И кое-что я действительно нашёл, но, как оказалось, не очень много. Для начала, на случай если вы ранее не участвовали в дискуссиях на эту тему, представлю существующие мнения и их опровержения. Если же вам нужны факты, то можете сразу переходить в третий раунд.
Раунд 1: Мнения
За нижние подчёркивания:
Спасибо тебе, Йосси Крейнин, за 2 последних пункта, обсуждённых в IHateCamelCase.
За верблюжий регистр
Раунд 2: Опровержения
Против нижнего подчёркивания
Против верблюжьего регистра
Раунд 3: Факты
При чтении краткого изложения исследовательской статьи возникает ощущение, что наука на стороне верблюжьей нотации.
Результаты показывают, что использование верблюжьей нотации позволяет всем, независимо от подготовки, точно распознавать идентификаторы, а те, кто привык читать в верблюжьем регистре способны распознавать идентификаторы в этом стиле быстрее, чем те, которые написаны с подчёркиваниями.
Существующие исследования
Исследования естественных языков в психологии показывают, что замена пробелов на другие символы или цифры негативно влияет на чтение. Однако затемнённые квадратики (похожи на подчёркивания) не оказывают существенного влияния на скорость чтения или точность распознавания отдельных слов. Удаление же всех пробелов замедляет чтение приблизительно на 10-20%.
Подготовка эксперимента
Эмпирическое исследование 135 программистов и не-программистов. Испытуемым нужно было корректно определить соответствующую фразу (не более трёх слов) из четырёх схожих вариантов. Измерялись следующие показатели:
Результаты
Заключение
Взглянув на все результаты вместе, становится очевидно, что верблюжья нотация обеспечивает выигрыш как по скорости, так и по точности, при условии, что испытуемый уже привык применять этот стиль. Причём предварительная подготовка необходима только для скорости распознавания.
Обсуждение
Лично я считаю вывод ошибочным по нескольким причинам.
Обсуждая возможные угрозы для точности, они упоминают следующее: «В сущности, весь тренинг проходил с верблюжьим регистром, было бы интересно изучить людей, натренированных использовать нижние подчёркивания.» С учётом этого результаты (4) и (5) выглядят необъективными. Разве не очевидно, что люди, привыкшие к верблюжьей нотации, будут хорошо в ней ориентироваться? И это точно имеет негативное влияние на «скорость поиска» в случае подчёркиваний.
Таким образом, остаётся только низкая скорость чтения в верблюжьем регистре (2). В среднем, чтение идентификатора в верблюжьем регистре занимает на 13,5% больше времени, чем с нижними подчёркиваниями. Умножьте это на весь объём кода, и вы узнаете моё мнение в войне между верблюжьей нотацией и подчёркиваниями!
Итак, каково ваше мнение сейчас? Снова постарайтесь выбрать независимо от соглашений, привычек или типа идентификатора.
Обновление Я обсудил очередное исследование в новом посте. Они воспроизвели исследование, и по их измерениям чтение идентификаторов в верблюжьей нотации занимает на 20% больше времени, и вдобавок, используя систему слежения за глазами, они выяснили, что идентификаторы в верблюжьем регистре требуют в среднем больше времени для фиксации глаз.
Что такое CamelCase или CamelStyle?
Существует целый свод правил, который называется Code Conventions в Java. Так что можете смело заходить и изучать.
А сейчас в этой статье мы рассмотрим только часть Code Conventions, а именно правила написания названий классов, переменных и методов. Итак, запоминаем.
Правило №1: Названия должны быть «говорящими»
То есть везде, где возможно, желательно давать названия классам, переменным, методам такие, чтобы уже из названия было понятно за что отвечает класс, переменная или метод.
Например, что понятнее?
Конечно же, int size, потому что из названия понятно, переменная отвечает за размер чего-то.
Правило №2: Применяется всегда CamelStyle
Пример №1
Допустим, мы хотим дать название переменной, которая отвечает, скажем, за размер коробки. Тогда назовем переменную так:
Пример №2
Допустим переменная отвечает за мои товары, которые я продаю в Германии:
И еще одна переменная, которая отвечает за мои товары, которые я продаю в Польше:
В приведенных примерах, если слово состоит из 2 и более слов, слова пишутся слитно и при этом каждое слово с большой буквы. Таким образом, образуются как бы «горбики», как у верблюда. Отсюда и называние CamelStyle.
