← Блог · 19 апреля 2026 г. · Команда ConvertCaseHQ · 6 мин чтения

camelCase, snake_case, kebab-case: шпаргалка для разработчиков

Вот краткая версия. Типы и классы почти во всех языках пишутся в PascalCase. Переменные и функции в JavaScript, Java, C#, Kotlin и Swift пишутся в camelCase, а в Python, Ruby и Rust — в snake_case. Константы в большинстве языков пишутся в SCREAMING_SNAKE_CASE; исключения — Go, Swift, C# и C++ в стиле Google. Всё, что попадает в URL, файл CSS или имя пакета, обычно пишется строчными буквами в kebab-case, а переменные окружения — заглавными буквами с подчёркиваниями.

Такова общая картина. Споры в код-ревью идут о деталях, поэтому эта шпаргалка опирается на то, что на самом деле говорит официальное или самое распространённое руководство по стилю каждого языка, и для каждого языка называет источник.

camelCase, snake_case, kebab-case: пять стилей и их другие названия

• camelCase (orderTotal): первое слово строчными буквами, каждое следующее — с заглавной. Ещё называется lowerCamelCase; в PEP 8 он называется mixedCase.
• PascalCase (OrderTotal): каждое слово с заглавной буквы. Ещё UpperCamelCase, CapWords (PEP 8) или StudlyCaps (PSR-1 в PHP).
• snake_case (order_total): слова строчными буквами, соединённые подчёркиваниями.
• SCREAMING_SNAKE_CASE (ORDER_TOTAL): слова заглавными буквами, соединённые подчёркиваниями. В руководстве Google по JavaScript он называется CONSTANT_CASE, а в руководстве по Java — UPPER_SNAKE_CASE.
• kebab-case (order-total): слова строчными буквами, соединённые дефисами. В большинстве языков его нельзя использовать для идентификаторов, потому что дефис — это знак минус.

Чтобы переключить имя из одного стиля в другой, вставьте его в наш конвертер регистра. Он разбивает текст по пробелам, подчёркиваниям, дефисам и уже имеющимся заглавным буквам, поэтому order_total, order-total и OrderTotal чисто превращаются друг в друга. Но обрабатывайте по одному имени: всё, что есть в поле, он считает одним идентификатором.

Шпаргалка: соглашения об именовании по языкам

Несколько строк требуют пояснения. В Go первая буква вообще не вопрос стиля, это правило видимости. Area экспортируется из своего пакета, а area нет, и за этим следит компилятор. В C++ нет общего для всего языка соглашения; сама стандартная библиотека использует snake_case (std::unordered_map, push_back), поэтому воспринимайте строку Google как один хорошо задокументированный вариант, а не как правило.

Rust необычно строг к стилю. Компилятор предупреждает сразу, без настройки: напишите fn GetUser() или struct user_account, и rustc предложит get_user и UserAccount ещё до запуска линтера.

Имена файлов, модулей и пакетов

• Java: публичный класс верхнего уровня должен лежать в файле с точно таким же именем, включая заглавные буквы. OrderService идёт в OrderService.java, и javac отвергает любой другой вариант.
• Kotlin: файл с одним классом называют по имени этого класса. Остальным файлам дают описательное имя в UpperCamelCase, например ProcessDeclarations.kt.
• Python: модулям дают короткие имена целиком строчными буквами, с подчёркиваниями, если они улучшают читаемость. Пакеты тоже должны быть короткими и строчными, и PEP 8 не советует использовать в них подчёркивания.
• Ruby: файлы в snake_case, названные по классу внутри, так что HelloWorld лежит в hello_world.rb.
• Go: имена пакетов — отдельные слова строчными буквами, без подчёркиваний и mixedCaps: base64, а не encoding_base64 или encodingBase64.
• JavaScript и TypeScript: единого правила нет. Руководство Google по JavaScript требует имена файлов целиком строчными буквами, с подчёркиваниями или дефисами, а его руководство по TypeScript использует snake_case. По руководству Airbnb имя файла должно совпадать с экспортом по умолчанию, так что класс CheckBox лежит в CheckBox.js. Выберите один вариант на проект и запишите его.
• Пакеты npm: в именах новых пакетов вообще нельзя использовать заглавные буквы.

За пределами исходного кода: переменные окружения, CSS, HTML, URL, JSON и SQL

Одна странность с переменными окружения: по POSIX стандартные утилиты используют имена заглавными буквами, а имена со строчными буквами зарезервированы для приложений, так что имя строчными никогда не столкнётся со стандартным. Заглавные буквы всё равно остаются устоявшейся привычкой, поэтому мы бы придерживались её, а столкновений избегали бы с помощью характерного префикса (MYAPP_TIMEOUT).

У строк про CSS и SQL есть отдельные статьи: про имена классов читайте в материале об именовании в CSS и БЭМ, а почему базы данных подталкивают вас к строчным буквам, объясняют соглашения об именовании в SQL.

Аббревиатуры: в чём руководства расходятся

Насчёт userName согласны все руководства. А вот userID их разделяет. Руководства Google по JavaScript и Java пишут аббревиатуры строчными буквами, как обычные слова (xmlHttpRequest, customerId). Go оставляет у каждой аббревиатуры один регистр (ServeHTTP, appID). Рекомендации Microsoft для .NET пишут заглавными обе буквы двухбуквенной аббревиатуры (IOStream), а у более длинных — только первую (HtmlTag). Rust считает их словами (Uuid), а PEP 8 предпочитает HTTPServerError варианту HttpServerError. Эти варианты мы сравниваем бок о бок в статье camelCase и PascalCase.

Как выбирать, если вы не уверены

1. Проверьте, не решает ли за вас платформа. Имена свойств CSS, имена файлов Java, экспортируемые имена в Go и имена компонентов React (они должны начинаться с заглавной буквы) — не вопрос стиля.
2. Следуйте официальному руководству языка. Новый код должен выглядеть как стандартная библиотека, рядом с которой он стоит.
3. Подстраивайтесь под существующий проект. PEP 8 говорит об этом прямо: единообразие внутри проекта важнее единообразия с руководством по стилю.
4. Поручите помнить об этом линтеру. Правило ESLint camelcase, правила N в Ruff для Python и встроенные предупреждения rustc ловят промахи раньше, чем это придётся делать ревьюеру.
5. Преобразуйте один раз на границе. Когда JSON в snake_case встречается с JavaScript в camelCase, переименуйте ключи в одном слое сериализации, а не позволяйте обоим стилям расползаться по всей кодовой базе.