Конвенции названия: camelCase vs snake_case vs kebab-case vs PascalCase

Известная шутка Фила Карлтона гласит, что в компьютерной науке есть только две сложные вещи: аннулирование кэша и присвоение названий вещам. Достаточно сложно выбрать хорошие слова; затем вы также должны решить, как присоединиться к ним. userId, user_id, UserId, user-id и USER_ID все описывают одно и то же понятие, и каждый где-то правильный. В этом руководстве объясняются основные конвенции, где ожидается каждая из них, и как справиться с неловкими случаями аббревиатуры, цифры и границы между системами.

Основные конвенции

Имя	Пример	Типичное применение
КамельСлучай	getUserById	Переменные и функции JavaScript/TypeScript, методы Java, поля JSON
Паскальский случай	UserProfile	Классы, типы, компоненты React, методы C#
Снежка	get_user_by_id	Python, Ruby, Rust функции, SQL столбцы
Скриминг_СНЕК_ЧАС	MAX_RETRIES	Постоянные, переменные окружающей среды
Каба-кейс	user-profile	URL-адреса, классы CSS, атрибуты HTML, имена файлов, флаги CLI
Поездный корпус	Content-Type	Заголовки HTTP
точка.дело	app.server.port	Ключи конфигурации, пакеты Java

[case-converter] ((/tools/case-converter) может переводить любое имя между всеми этими сразу, что удобно при перемещении данных между слоями.

Конвенции по языку и контексту

JavaScript и TypeScript

• Переменные, функции и свойства объектов: camelCase.
• Классы, интерфейсы, псевдонимы типов, списки и компоненты React: PascalCase. React требует, чтобы компоненты начинались с большой буквы, чтобы JSX мог отличить их от элементов HTML.
• Истинные константы (конфигурация, которая никогда не меняется): SCREAMING_SNAKE_CASE, хотя многие кодовые базы используют camelCase для переменных const.
• Имена файлов: часто kebab-case (user-profile.tsx) или PascalCase для компонентных файлов. Выберите один; смешанные буквы в названиях файлов вызывают проблемы в системах файлов, не чувствительных к буквам.

Питон

PEP 8 является ясным: snake_case для функций, переменных и модулей, PascalCase (который PEP 8 называет CapWords) для классов и SCREAMING_SNAKE_CASE для констант уровня модуля. Внутренняя линия подчеркивает: _cache.

Иди .

Go использует camelCase и PascalCase, а case имеет значение: идентификаторы, начинающиеся с большой буквы, экспортируются из пакета, малые буквы являются частными. В стиле Go аббревиатуры заглавными буквами: userID, HTTPServer, parseURL.

Java и C#

Оба используют PascalCase для классов и camelCase для локальных переменных. Java использует camelCase для методов; C# использует PascalCase для методов и публичных свойств.

Ржавчина

snake_case для функций, переменных и модулей; PascalCase для типов и признаков; SCREAMING_SNAKE_CASE для констант и статики. Компилятор предупреждает, когда вы отклоняетесь.

Базы данных SQL

snake_case является безопасным выбором для таблиц и столбцов. В PostgreSQL нецитируемые идентификаторы складываются в миниатюрные буквы, поэтому столбец, созданный как "userId", должен быть цитирован навсегда, в то время как user_id работает везде. Независимо от того, однозначны ли названия таблиц (user) или множественные (users), это вопрос предпочтений команды; согласованность имеет большее значение, чем выбор.

CSS и HTML

CSS-свойства являются кебаб-case (background-color), поэтому имена классов обычно следуют: .card-header. Методологии, такие как BEM, добавляют структуру: .card__title--active. Атрибуты HTML, в том числе атрибуты data-*, не чувствительны к буквам большого и маленького числа; JavaScript выставляет data-user-id как element.dataset.userId.

URL-адреса

Используйте заглавные буквы kebab-case для путей: /blog/compress-image-to-100kb. Google рассматривает дефисы как разделители слов, но подчеркивает как соединители, поэтому дефисы лучше для SEO. Избегайте заглавных букв в URL-адресах; многие серверы рассматривают пути как чувствительные к заглавным буквам, создавая проблемы с дублированным контентом.

Переменные среды

SCREAMING_SNAKE_CASE, DATABASE_URL, STRIPE_SECRET_KEY. В оболочках и контейнерных платформах этого ожидают, а некоторые вообще не допускают дефисов в названиях переменных.

Акронимы и инициализмы

Здесь команды больше всего спорят. Должно быть parseHTTPResponse или parseHttpResponse? userID или userId?

• ** Обращайтесь с аббревиатурами как со словами** (parseHttpResponse, userId, XmlParser): рекомендуется в руководствах Microsoft .NET для аббревиатур длиннее двух букв, в руководствах Google по стилю Java и JavaScript и во многих кодовых базах TypeScript. Он избегает непрочитываемых ходов, таких как HTTPSURLConnection, и преобразует чисто между случаями parseHttpResponse становится parse_http_response автоматически.
• ** Keep acronyms uppercase** (parseHTTPResponse, userID): стандартный в Go и распространенный в старых кодах Java и Objective-C.

Автоматические преобразователи разделяют parseHTTPResponse на parse / HTTP / Response, что работает, но HTTPSURLConnection неоднозначен. Если вы контролируете стиль, обращение с аббревиатурами как со словами более надежно.

Цифры в именах

Соединяйте цифры со словом, к которому они относятся: version2, utf8Decoder, base64_encode, h1-title. Избегайте начала идентификаторов цифрами; большинство языков запрещают это, а классы CSS, начинающиеся с цифрами, требуют ухода.

Пересечение границ: API и базы данных

Реальные системы смешивают конвенции. Python-бакенд с snake_case обслуживает JavaScript-фронт-энд, который ожидает camelCase, поддерживаемый SQL-базой данных с столбцами snake_case. Опции:

1. ** Используйте одну конвенцию на проводе.** Решите, что JSON использует camelCase (наиболее распространенный выбор для публичных API, соответствующий JavaScript) или snake_case (обычный в экосистемах Python и Ruby и используемый такими API, как Stripe и GitHub). Запишите это и применяйте повсюду.
2. Конвертировать на краях. Библиотеки сериализации могут конвертировать автоматически: генераторы псевдонима Pydantic, PropertyNamingStrategies Джексона или колонные mappings ORM. Внутри каждого слоя код остается идиоматическим.
3. Не смешивайте в пределах одной полезной нагрузки. { "userId": 1, "created_at": "..." } - худшее из обоих миров.

При генерации типов TypeScript из JSON , охваченных [нашим руководством по JSON к TypeScript] ((/blog/json-to-typescript-interfaces) сохраняйте имена свойств точно такими, как они появляются на проводе, и конвертируйте в слой отображения, если это необходимо.

Как правильно говорить

Стиль дела - легкая часть. Несколько правил для самих слов:

• Будьте конкретны. data, info и item ничего не говорят. invoiceLines много говорит.
• ** Используйте глаголы для функций и существительные для значений.** calculateTotal() возвращает total.
• Назовите булевы в качестве вопросов. isActive, hasAccess, shouldRetry.
• Включают единицы. timeoutMs, maxSizeBytes, durationSeconds предотвращают целый класс ошибок.
• ** Избегайте аббревиатур**, если они не являются универсальными (id, url, html). usrCnt сохраняет четыре персонажа и стоит каждому читателю минуту.
• ** Сопоставьте язык домена.** Если в бизнесе написано "подписка", не называйте его plan в коде.

Применение конвенций

Запишите конвенции и позвольте инструментам применять их: правило @typescript-eslint/naming-convention ESLint, Pylint и Ruff для Python, golint и go vet, встроенные линты Rust и стилевые линты для шаблонов классов CSS. Автоматизированные проверки заканчивают дебаты по пересмотру кодов и сохраняют последовательность больших кодовых баз.

Итоги

Используйте camelCase для значений JavaScript, PascalCase для типов и компонентов, snake_case для Python, Rust и SQL, kebab-case для URL-адресов, CSS и имен файлов, и SCREAMING_SNAKE_CASE для констант и переменных окружающей среды. Обращайтесь с аббревиатурами как со словами, когда это возможно, храните единицы в названиях, выбирайте одну конвенцию для каждого API и позволяйте линтерам применять правила, чтобы люди могли сосредоточиться на выборе хороших слов.