Snake case что это

Стили именования переменных и функций. Используйте их все

Авторизуйтесь

Стили именования переменных и функций. Используйте их все

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

В программировании пробел является зарезервированным символом, поэтому все названия обходятся без него. Чтобы строки без пробелов всё же напоминали естественный язык и нужны все эти кейсы.

camelCase (dromedaryCase)

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

PascalCase (CamelCase, StudlyCase)

В этом стиле каждое слово начинается с заглавной буквы. Обычно используется для названий классов.

snake_case (pothole_case)

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

SCREAMING_SNAKE_CASE (MACRO_CASE, CONSTANT_CASE)

Тот же snake_case, только буквы всегда в верхнем регистре. Обычно используется для именования констант.

kebab-case (dash-case, lisp-case)

В этом случае пробел заменяется дефисом. Используется в URL и CSS. В языке Lisp так пишутся любые названия. Примеры:

TRAIN-CASE (COBOL-CASE, SCREAMING-KEBAB-CASE)

Все буквы в верхнем регистре, соединены дефисом. Применяется в языке COBOL для всех названий. Пример:

Train-Case (HTTP-Header-Case)

Каждое слово с большой буквы, соединены дефисом. Стиль названий HTTP заголовков. Пример:

flatcase

Все слова в нижнем регистре, без пробелов. Используется в тегах. Пример:

Источник

Camel, Pascal, Snake Case и другие стили написания

Jul 25, 2020 · 4 min read

Разбираемся в зоопарке стилей написания составных слов в JS — зачем столько и для чего они нужны.

Заставьте 10 человек нарисовать одну и ту же картинку и вы получите д е сять совершенно разных изображений — и чем сложнее исходник, тем больше будет отличий между репликами. То же самое справедливо и для кода. Там, где заканчиваются строгие правила языка и начинается творчество разработчика, код становится похож на рукописный текст — он имеет свой стиль, структуру, почерк. У кого-то почерк четкий и понятный, а у кого-то сложно даже просто разобрать написанное. Чтобы один разработчик понял другого, существует масса гласных и негласных правил. Этой же цели служат и стили написания.

Функция у стилей написания всего одна — уложить в одну неделимую строку сложное, составленное из нескольких слов, название переменной, метода, свойства и тому подобное. Потому что в JavaScript, как и во многих других языках программирования, нельзя просто взять и написать:

Пробел является зарезервированным символом, поэтому парсер языка будет воспринимать user, login и count как отдельные сущности, в результате чего вы получите SyntaxError.

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

Camel case (camelCase)

«Верблюжий регистр » — по аналогии с горбатым красавцем каждое следующее слово в цепочке начинается с заглавной буквы.

Этот стиль, пожалуй, можно назвать самым популярным в JS. Он подходит для именования переменных и методов. Его можно назвать наиболее консистентным, так как он используется и для именования стандартных методов — setTimeout, toValue, toLocaleDateString.

Pascal case (PascalCase)

Очень схож с camelCase, но первое слово в строке так же пишется с заглавной буквы. Настолько схож, что часто его относят к разновидности camelCase — якобы есть традиционный camelCase как lowerCamelCase и его частный случай PascalCase как UpperCamelCase. По крайней мере, в этом нас убеждает русскоязычная википедия. Но если перейти на англоязычную версию и покопаться в источниках, то можно найти небольшую заметку 2004 года в блоге Microsoft от Брэда Абрамса — “History around Pascal Casing and Camel Casing”, в которой говорится что термин PascalCase абсолютно логично проистекает из языка Pascal, стандартные методы которого именуются с заглавной буквы ( Abs, Random, Round). В JS PascalCase используется для именования типов и классов:

Опять же, такой стиль применяется и в именовании стандартных классов JavaScript — RegExp, ResizeObserver.

Snake case (snake_case)

«Змеиный регистр » — заменяет пробелы на символ подчеркивания. В JS он отлично подходит для именования полей в базах данных, или для именования статичных данных, хранящихся в JSON.

Во-первых, по сравнению с camelCase и PascalCase глаз быстрее “парсит” такую строку. Представьте себе json-словарь, к примеру, c перечнем цветов в стиле PascalCase:

Сложно прочитать, правда? А если таких строк сотня?

А теперь тот же словарь в стиле snake_case:

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

Во-вторых, в этом случае snake_case позволяет сразу отличить данные, которые нельзя мутировать (перезаписывать).

В-третьих, в отличии от kebab-case, который мы рассмотрим ниже, snake_case всё также дружит с парсером языка и вы можете легко использовать его:

Screaming snake case (SCREAMING_SNAKE_CASE)

Его ещё иногда называют UPPER_CASE_SNAKE_CASE. Этот стиль стоит особняком. Думаю, все согласятся, что писать таким образом весь код категорически не рекомендуется. Он используется только для акцентирования внимания. До появления в JS настоящих констант, он был особенно актуален для их именования. Таким образом можно было выделить переменную, которая ни в коем случае не должна быть изменена. Теперь же достаточно объявить её с помощью const и в случае попытки перезаписать её вы получите TypeError. Но такой стиль именования по-прежнему используют для лучшей читабельности кода:

Kebab case (kebab-case)

Его также называют spear-case, и он является стандартом в Lisp. Он может с легкостью использоваться в языках, которые не требуют пробелов между операторами и выражениями. Но, к сожалению, JS к таковым не относится. К примеру, чтобы обратиться к свойству объекта с подобным ключом, придется обернуть его в кавычки:

Но почему тогда мы всё равно встречаем его в JS?

Их всех перечисленных стилей kebab-case является наиболее читабельным для обычного человека, не разработчика. Поэтому он используется там, где его может увидеть пользователь. Например, в URL-адресах (www.blog.com/cool-article-1) или в названиях скачиваемых файлов (cool-article-1.pdf).

Нельзя назвать какой-либо из стилей предпочтительным — каждый уместен при правильном использовании. Как правило, на проекте используется несколько стилей для разных мест и это только повышает читабельность кода. Одно из качеств хорошего разработчика — это умение легко переходить с одного стиля на другой и подстраиваться под то, что используется в конкретном проекте. Если вы повсеместно использовали camelCase, а в новой команде от вас просят snake_case, то для вас не должно составить труда писать именно так.

Удачи вам в разработке и спасибо за внимание!

P. S. Все мы люди 🙂 А значит, нам свойственно ошибаться.

Увидели опечатку или ошибку — выделите текст, кликните в всплывающем меню иконку сообщения с замочком и напишите о ней.

Источник

понедельник, 27 января 2020 г.

CamelCase, snake_case и другие регистры

CamelCase (с англ. — «ВерблюжийРегистр») — стиль написания составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое слово внутри фразы пишется с прописной буквы. Стиль получил название CamelCase, поскольку прописные буквы внутри слова напоминают горбы верблюда.

Регистр CamelCase обычно используется внутри кода для названия переменных.

snake_case (с англ. — змеиный_регистр) — стиль написания составных слов, при котором несколько слов разделяются символом подчеркивания (_), и не имеют пробелов в записи, причём каждое слово обычно пишется с маленькой буквы — «foo_bar», «hello_world» и т. д.

lower case — все буквы написаны в нижнем регистре

UPPERCASE — все буквы написаны в верхнем регистре (Его же называют «записано в капслоке» (CAPSLOCK)

Когда это нужно тестировщику

Для любой проверки на регистрозависимость. Например, когда вы тестируете REST-метод. Верно ли, что заголовки регистронезависимы? Это не опция по умолчанию, а сознательный выбор разработчика.

Важно понимать, что «Newparam» ≠ «newparam» ≠ «NewParam» ≠ «NEWPARAM».

Поэтому можно проверить разные варианты написания заголовков, чтобы посмотреть, что работает, а что нет.

PS — статья написана в помощь студентам моей школы для тестировщиков

Источник

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

Пять способов соединить слова в одно длинное название — с вариациями и пояснениями.

Часто для хорошего имени переменной или метода программистам не хватает одного слова. Например, название метода 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

Источник

Стили написания составных слов в программировании

Перевод статьи Чейза Адамса «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

Другие соглашения

Таблица для быстрого сравнения

Теперь, зная самые распространенные стили написания, вам будет легче определиться, какой использовать при написании своего кода!

Источник