Что такое snake case
Справка по case: camelCase, kebab-case, PascalCase, snake_case и другие
Oct 1, 2020 · 2 min read
Общее правило для всех кейсов — никаких специальных символов и пробелов. Далее по-порядку:
camelCase
Первая буква всегда маленькая, далее каждое слово начинается с большой буквы.
Применяется в именах файлов, атрибутах и именах переменных/методов/свойств, uri, в языках разметки.
Лучший для: имен переменных, свойств, модулей и файлов с ними.
PascalCase
Тоже что camelCase, только первая буква всегда заглавная.
Преимущества все те же, что у camelCase, а так же:
Применяется для имен классов, мето д ов (в некоторых языках, таких как c#), enum, имен файлов содержащих классы или компоненты. Часто используется вместе с camelCase, что бы визуально разделить классы от экземпляров, свойства от методов. Так же применим для наименования синглтонов.
Лучший для: имен классов, enum, синглтонов и файлов с ними.
kebab-case
Все буквы маленькие, слова разделяются дефисом.
Применяется в url, в именах директорий, в именах свойств JSON, в именах атрибутов HTML.
Лучший для: имен директорий, URI, имен свойств JSON.
snake_case
Все буквы маленькие, слова разделены нижним подчеркиванием
Применим практически везде, но ввиду того, что в большом количестве раздражает взгляд, на практике используется только для ключей и идентификаторов, или если есть системные ограничения на используемые символы.
Лучший для: ключей, идентификаторов, архаичных систем.
SCREAMING_SNAKE_CASE
Все буквы большие, слова разделяются нижних подчеркиванием.
Приемущества все те же, что у snake_case, а так же:
Недостатки все те же, что у snake_case, а так же:
Применяется в именах констант и переменных окружения.
Лучший для: имен констрант, переменных окружения.
Train-Case
Каждое слово начинается с заглавной буквой, слова разделяются дефисом.
Приемущества те же, что у kebab-case, а так же:
Применяется в загаловках запросов. Других кейсов применения не встречал.
Кратко о нейминге в JS
Привет, Хабр! Решил затронуть тему наименования сущностей в Javascript. По работе довольно много взаимодействую со стажёрами и насмотрелся всякого. Вот и подумал, что было бы неплохо собрать в одной небольшой заметке принятые на сегодняшний день правила наименования сущностей в JavaScript сообществе. Возможно собрал не все, поэтому буду признателен если дополните меня в комментариях.
Именование сущностей
Именование очень важно в разработке ПО. Как мы знаем, код пишется в первую очередь для людей, которые будут его читать(для программистов). Неудачное именование может существенно повысить трудозатраты на разработку или поддержку проекта из-за того, что будет тратится лишнее время на чтение кода, т.к. при плохом нейминге затруднён процесс интерпретации «что есть что в коде».
Существуют разные синтаксические формы наименования, их очень много, некоторые уже не употребляются. Вот самые употребимые в js:
Однобуквенные идентификаторы
В институтах очень часто используют однбуквенные идентификаторы в коде. Я вижу этот стиль кодирования у половины ребят, которые приходят после ВУЗов. Это очень порочная практика. Название должно наглядно описывать сущность. В наше время использовать однобуквенные идентификаторы — признак дурного тона. Исключениями могут быть счётчики и индексы, т.е. ситуации, где и одной буквы более чем достаточно для передачи сути сущности.
Транслит в имени
Также очень популярно среди студентов использовать транслит. Разумеется это тоже признак дурного тона и плохого кода. Никакого транслита в нейминге быть не должно, т.к. общепринятым языком в программировании является английский. Разрабатывая код мы должны использовать международный язык, который знают профессионалы в любой стране. Русский транслит к таковым не относится.
Именование переменных и классов
Переменные именуются в lower camelCase :
Классы именуются в CamelCase :
Действия
Очень важно для нейминга действий(например, функций) использовать глаголы. Нужно выбирать такой глагол. который соответствует типу действия.
Например:
checkNumberIsEven — хорошее название. сразу понятно, что функция проверяет число на чётность.
Также хорошее название isEven — если эта функция лежит в каком — нибудь /helpers/number.js, то даже такого короткого названия более чем достаточно, т.к. сама директория указывает нам на то, что в неё лежат функции по работе с числами.(но даже тут можно использовать первый вариант, т.к. в файле, который использует данную функцию, может быт довольно много кода, а вызов быть где нибудь в середине. )
Функции далеко не всегда являются действиями, это тоже важно понимать.
Например,
Эта функция генерирует нам арифметическую прогрессию, но действием не является, т.к. в виду своей декларативности считается определение арифметической прогрессии. Важно уметь различать этот момент. Сюда же относятся функции определяющие константы.
Предикаты
Выше мы обсуждали функцию
Такой тип функций называют предикатами. Предикат — утверждение о чём либо. Так называют функции выполняющиеся проверки «сущность есть что-то». Предикат в программирование всегда возвращает булевое значение.
Как правило предикаты именуются через форму третьего лица единственого числа английского вспомогательного глагола to be, т.е. is.
Некоторые предикаты определяют вхождение(наличие) искомого элемента(свойства или метода или item’a) в сущности. Такие предикаты. как правило начинаются с английского глагола has(3е лицо единственное число глагола to have). Например, безопасная форма Object.prototype.hasOwnProperty может выглядеть так:
Если сущность представляет собой количество чего-либо, то стоит использовать слово count в названии.
Нотации в программировании: верблюд, змея, шашлык и другие
Пять способов соединить слова в одно длинное название — с вариациями и пояснениями.
Анастасия Телесницкая для Skillbox Media
Часто для хорошего имени переменной или метода программистам не хватает одного слова. Например, название метода 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 или другие из нашего каталога курсов. Бонусом к правилам наименования — навыки программирования на выбранном языке, а потом и помощь в трудоустройстве.
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 — статья написана в помощь студентам моей школы для тестировщиков