Snake case python что это
Перейти к содержимому

Snake case python что это

  • автор:

Snake_case — Что это в программировании

melisa's picture

Snake_case(«Змеиный стиль») — в программировании — это стиль написания имён переменных/констант, при котором все слова имени разделяются нижним подчёркиванием (_), без пробела:

Некоторые исследования показали, что «Змеиный стиль» распознаётся человеком быстрее, чем «Верблюжий стиль» (CamelCase).

Если все слова написаны в нижнем регистре, такой стиль написания также называют under_score.

Вариации snake_case

  1. Дефисы вместо нижнего подчёркивания:

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

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

Анастасия Телесницкая для Skillbox Media

Екатерина Степанова

Екатерина Степанова

Фулстек-разработчик. Любимый стек: Java + Angular, но в хорошей компании готова писать хоть на языке Ада.

Часто для хорошего имени переменной или метода программистам не хватает одного слова. Например, название метода calculate, конечно, намекает на то, что в нём что-то вычисляется, но что конкретно — непонятно, нужны ещё слова.

Проблема с языками программирования в том, что пробелы в названиях там недопустимы — нельзя назвать метод calculate elephant weight. Поэтому появились многочисленные варианты соединения слов с помощью изменения регистра букв или дописывания символов-разделителей.

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

Расскажем, какие нотации существуют и для чего они используются.

О чём пойдёт речь:

  • Верблюжья нотация (сamel case, camelCase)
  • Нотация Паскаля (Pascal case, PascalCase)
  • Змеиная нотация (snake case, snake-case)
  • Шашлычная нотация (kebab case, kebab-case)
  • Плоская нотация (flat case, flatcase)
  • Как выбрать нотацию

Верблюжья нотация (сamel case, camelCase)

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

Пример

Используется во многих языках программирования для именования переменных, функций, методов — например, в Java, JavaScript, PHP. В языке Go в camelCase объявляют внутренние поля и методы.

Язык Go вообще чувствителен к именам: от того, с какой буквы, строчной или заглавной, начинается имя переменной, зависит её область видимости — то, какие другие компоненты приложения смогут к этой переменной обратиться.

Для внутренних переменных подходит camelCase, а для публичных (экспортируемых) обязательно делать первую букву названия заглавной, то есть именовать в стиле PascalCase.

Нотация Паскаля (Pascal case, PascalCase)

Тот же camelCase, но все слова, даже первое, начинаются с заглавной буквы.

Пример

В таком стиле часто именуют классы (в Java, Python, JavaScript), а в программной платформе .NET — ещё и переменные.

Стиль так называется вовсе не в честь Блеза Паскаля. 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 или другие из нашего каталога курсов. Бонусом к правилам наименования — навыки программирования на выбранном языке, а потом и помощь в трудоустройстве.

Открытый вебинар «Как не нужно писать на Python»

Всем привет! В рамках нашего курса «Разработчик Python» мы провели ещё один открытый урок на тему «Как не нужно писать на Python». Занятие вёл преподаватель и создатель курса Станислав Ступников, имеющий большой опыт промышленной и научной разработки. Рассматривались антипаттерны программирования, bad practice и прочее зло, о котором нужно знать и которого следует избегать в процессе написания кода.

Подробности смотрите в видео и кратком изложении. Внимание: некоторые примеры кода не рекомендуется запускать на своём компьютере!

В процессе проведения открытого урока преподаватель показывал слайды, сгенерированные с Jupyter Notebook.

Так как же не стоит писать на Python?

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

  • Diaper pattern. Речь шла о так называемом паттерне «подгузника», под которым обычно подразумевается слишком широкий try-except. Например, вы вызываете функцию, которая является обёрткой к чему-нибудь, допустим, оборачивает клиентскую либу для какой-то базы. В хорошем случае (система маленькая) всё будет нормально в 99 % случаев, но если система большая, то вероятности возникновения проблемы умножаются не самым хорошим образом. В итоге постоянно что-то падает или ломается.
  • Antiglobalism. Всем известно, что глобальные переменные неэффективны, кроме каких-нибудь исключительных случаев. Гораздо лучше всё передавать в виде атрибутов функции и т. д., и т. п., добиваясь нужных результатов. Однако некоторым приходит в голову «отличная идея» — использовать изменяемые объекты. Она заключается в том, чтобы передавать в функции не глобальные переменные, а изменяемые объекты, после чего изменять их внутри и потом ничего назад не возвращать. Это же так круто!) По сути, кусочек шаблона программирования из языка С, перенесённый в мир Python.
  • Stairway to Heaven. Как вы уже догадались, это «лестница в небо». Лучше всего данную проблему характеризует простая картинка:

  • Javatar. Ошибки этого плана часто делают те программисты, которые по тем либо иным причинам перешли с Java на Python. Естественно, они приходят со своим уставом, поэтому массово нарушают правила разработки Python. Это и появление безумных отступов, и CamelCase, и стремление создать побольше классов… В итоге структура кода усложняется. Там, где можно было бы обойтись скриптом размером в 300 строк, мы видим 10-20 файлов.
  • Overengineering. Очень часто вторая итерация какого-нибудь проекта либо никогда не завершается либо реализуется слишком сложным способом. Такое бывает, если вы хотите переписать уже существующий, но имеющий недостатки код, сделав его идеальным. При этом забываете о том, что лучшее — враг хорошего. В результате программист попадает в стандартную ловушку переинжиниринга, когда реализация становится более дорогой, тяжёлой и громоздкой, чем это необходимо для решения поставленных задач. И в самом деле: должны ли семейные седаны развивать скорость до 350 км/ч, а смартфоны, мода на которые меняется ежегодно, работать в течение 100 лет?
  • Oneliner. Очередная актуальная проблема — «однострочники». Речь о программистах, которые с завидным усердием пытаются всё запихнуть в одну строку, этажей эдак в пять)). Из-за избыточной сложности кода и особенностей реализации машинорегулярных выражений в Python такие скрипты иногда «залипают» на парсинге, поэтому для устранения проблемы приходится использовать специальный модуль.
  • Copy-on-Read. Это не столько ошибка, сколько особенность программирования на Python. Многим знаком подход Copy-On-Write. Его идея заключается в том, что при чтении какой-либо области данных используется общая копия, а при изменении создаётся новая копия, то есть речь идёт об оптимизации процессов производительности. Если говорить о Python, то в некоторых случаях мы не просто читаем массив из элементов, а обращаемся ко всем нижележащим структурам, которые находятся в памяти, то есть «перезаписываем» память, меняя её. Таким образом вместо Copy-On-Write у нас получается Copy-on-Read, когда мы как будто бы читаем память, однако на самом деле нам приходится копировать дочерним процессом эту информацию из родительского пространства к себе, от чего становится грустно, так как подход по оптимизации не работает, а потребление вырастает.
  • There is no fork. Fork — клонирование появления нового процесса. Проблема связана со спецификой работы с Unix-системами и неочевидностями некоторых структур данных, которые скрыты в имплементации. Под «форкнутым» процессом понимается процесс, который запускается в тот момент, когда тред захватил лог в очереди, чтобы в него что-нибудь положить. То есть возникший новый процесс тоже хочет кое-что записать, но для этого ему нужно захватить лог из этой самой очереди, но он не может этого сделать, так как лог уже захвачен. В результате мы получаем блокировку. Всё это лишь в очередной раз подтверждает то, что не стоит программировать, не зная особенностей имплементации среды, в которой работаете и инструментов, которые используете.
  • Было ещё много чего интересного, поэтому лучше посмотрите видео, т.к. пересказ всё же кортковат.

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

    • Блог компании OTUS
    • Python
    • Программирование

    camelCase ⇄ snake_case

    Напишите две функции tocamelcase() и tosnakecase() , которые принимают строку и конвертируют их в camelCase и snake_case соответственно.

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

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

    Примеры

    to_camel_case("hello_codechick") ➞ "helloCodechick" to_snake_case("helloCodechick") ➞ "hello_codechick" to_camel_case("is_modal_open") ➞ "isModalOpen" to_snake_case("getColor") ➞ "get_color" 

    Примечание

    • Поскольку camelCase и snake_case обычно используются для записи переменных, вам предстоит работать с латиницей.
    • На вход гарантированно поступают строки, оформленные либо в стиле camelCase, либо в стиле snake_case.
    • Учтите, что на вход может подаваться и одно слово. Тогда ни прописной буквы, ни знака _ в строке не будет.

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *