У програмуванні той самий ідентифікатор можна записати кількома способами: myVariable, MyVariable, my_variable, my-variable. Ці стилі не випадкові — кожен закріпився в певній мові чи контексті як конвенція, і змішувати їх в одному місці вважається поганим тоном.
Основні стилі
- camelCase — перше слово з малої, кожне наступне з великої, без роздільників:
userName. Стандарт для змінних і функцій у JavaScript, Java, C#. - PascalCase — те саме, але й перше слово з великої:
UserName. Використовується для класів і компонентів майже скрізь. - snake_case — слова через нижнє підкреслення, усе в малих літерах:
user_name. Стандарт Python і баз даних (назви колонок). - kebab-case — слова через дефіс:
user-name. Стандарт для URL, CSS-класів і HTML-атрибутів, оскільки підкреслення в URL менш звичне.
Чому це не просто естетика
Регістр символів технічно не впливає на роботу коду (за винятком мов, чутливих до регістру ідентифікаторів), але послідовність стилю впливає на читабельність і на автоматичні інструменти: лінтери, IDE з автодоповненням і генератори документації часто очікують конкретний стиль для конкретного типу сутності.
Навіщо потрібна конвертація
- Перенесення поля з JSON API (зазвичай camelCase) у назву колонки бази даних (зазвичай snake_case).
- Перейменування змінних при портуванні коду з однієї мови в іншу з іншою конвенцією.
- Генерація URL-сумісного slug чи CSS-класу з тексту заголовка.
Неоднозначність з абревіатурами
Ідентифікатор на кшталт userID чи XMLParser ставить конвертер перед вибором: вважати абревіатуру одним «словом» чи розбити її на окремі літери. Різні інструменти вирішують це по-різному — цей конвертер розпізнає послідовність великих літер як окреме слово (XMLParser → XML + Parser), але варто перевіряти результат вручну, якщо назва одразу піде в продакшн-код.