Конвертер регістру

• UPPERCASE перетворює кожну літеру на велику (HELLO WORLD).
• lowercase перетворює кожну літеру на малу (hello world).
• Title Case робить першу літеру кожного слова великою (Hello World).
• Sentence case робить великою лише першу літеру всього рядка (Hello world).
• camelCase об'єднує слова без роздільника, пишучи перше слово з малої літери, а наступні — з великої (helloWorld).
• PascalCase схожий на camelCase, але перше слово також пише з великої літери (HelloWorld).
• snake_case робить усі літери малими та об'єднує їх символами підкреслення (hello_world).
• kebab-case робить усі літери малими та об'єднує їх дефісами (hello-world).
• CONSTANT_CASE робить усі літери великими та об'єднує їх символами підкреслення (HELLO_WORLD).
• dot.case робить усі літери малими та об'єднує крапками (hello.world).
• Alternating case чергує великі та малі літери по черзі (hElLo WoRlD).

Кожен формат містить як правило роздільника, так і правило регістру, а наш конвертер обробляє всі комбінації вхідних і вихідних форматів.

Обидва формати об'єднують слова без роздільника. Різниця полягає у першій літері: camelCase робить її малою (myVariableName), а PascalCase — великою (MyClassName).

Загальноприйняті правила в сучасних мовах:

• camelCase для змінних, назв функцій та методів;
• PascalCase для назв класів, типів, інтерфейсів, переліків (enum) та компонентів React/Vue/Svelte.

• Приклад у JavaScript: const userAccount = getCurrentUser() — userAccount та getCurrentUser написані в camelCase; class UserAccount {} — UserAccount написаний у PascalCase.
• Java: int totalAmount, void calculateTotal() (методи та поля в camelCase), class Calculator (класи в PascalCase).
• C#: більш нюансовано — публічні властивості та методи використовують PascalCase (UserName, GetUserById), приватні поля використовують camelCase (часто з префіксом _).
• TypeScript дотримується конвенцій JavaScript плюс PascalCase для типів та інтерфейсів.
• Компоненти React мусять бути в PascalCase для коректного рендерингу — малі назви тегів інтерпретуються як елементи HTML.

snake_case є домінуючою конвенцією в динамічних мовах і мовах сценаріїв.

• Python PEP 8 вимагає snake_case для назв функцій, змінних, методів, модулів та пакетів: def calculate_total(user_id), total_amount = 0, import data_processor. Константи пишуться як CAPS_WITH_UNDERSCORES (MAX_RETRY = 5). Класи використовують PascalCase (class UserAccount).
• Ruby використовує snake_case скрізь — у методах, змінних, назвах файлів, тоді як константи пишуться в PascalCase або CONSTANT_CASE.
• SQL: стандартні назви таблиць та стовпців — це snake_case (user_accounts, created_at, last_login_date). Цитовані ідентифікатори зберігають регістр, але створюють вразливість у різних базах даних.
• JSON: API, згенеровані на Python та Ruby, зазвичай повертають назви полів у форматі snake_case (Stripe API, Twitter API, Django REST Framework).

Під час перетворення між бекендом на Python і фронтендом на JavaScript виберіть один стиль і проводьте конвертацію на межі API (наприклад, перехоплювач axios, генератори псевдонімів Pydantic).

kebab-case вимагається у трьох місцях:

• (1) Назви CSS-класів — .primary-button, .nav-link-active. Ідентифікатори JavaScript не можуть містити дефіси, тому в CSS обрали дефіси саме для того, щоб їх неможливо було сплутати з ідентифікаторами JavaScript.
• (2) URL-слаги — /blog/how-to-calculate-mortgage. Google прямо рекомендує дефіси замість підкреслень для розділення слів: дефіси сприймаються як розриви слів, а підкреслення — як з'єднувачі, тому 'best-running-shoes' індексується як три окремі терміни, тоді як 'best_running_shoes' — як один.
• (3) Назви HTML-атрибутів — зокрема атрибутів data-* та назв кастомних елементів Web Components. Специфікація Web Components вимагає, щоб назви кастомних елементів містили дефіс (my-component, а не myComponent), щоб відрізняти їх від стандартних елементів HTML.

Користувацькі CSS-властивості (змінні) також використовують kebab-case: --primary-color, --max-width. Коли фреймворки CSS-in-JS перетворюють назви властивостей, вони автоматично конвертують camelCase з JavaScript у kebab-case для CSS.

CONSTANT_CASE (також відомий як SCREAMING_SNAKE_CASE або UPPER_SNAKE_CASE) сигналізує «це значення ніколи не змінюється» у всіх основних мовах.

Випадки використання:

• (1) Константи на рівні мови — JavaScript const PI = 3.14159, Java public static final int MAX = 100, Python ABSOLUTE_PATH = '/etc', Go const MaxRetries = 5 (хоча Go часто використовує MixedCase для експортованих констант).
• (2) Значення enum — TypeScript enum Status { PENDING, IN_PROGRESS, COMPLETED }, Java public enum Status { PENDING, IN_PROGRESS }, елементи StrEnum у Python.
• (3) Змінні середовища — DATABASE_URL, NODE_ENV, AWS_ACCESS_KEY_ID в усіх ОС та фреймворках.
• (4) Макроси C/C++ — #define BUFFER_SIZE 1024, #define MAX_RETRY 5.
• (5) Розділи середовища в Docker compose YAML, Kubernetes ConfigMaps, секрети GitHub Actions, панелі керування Vercel/Netlify.

Візуальна відмінність у вигляді крику (SCREAMING) робить константи неможливими для сплутування зі змінними з першого погляду — у цьому й полягає весь сенс конвенції.

Title Case робить першу літеру кожного слова великою; Sentence case робить великою лише першу літеру всього речення, а також власні назви.

Різні посібники зі стилю розходяться в тому, які слова робити великими в Title Case.

• Стиль AP та APA: слова з 4+ літер пишуться з великої, але НЕ пишуться з великої короткі прийменники (in, on, at, of, by, to, for), артиклі (a, an, the) або сурядні сполучники (and, but, or, nor), якщо вони не є першим чи останнім словом.
• Чиказький посібник зі стилю: усі слова пишуться з великої літери, окрім артиклів, сурядних сполучників і прийменників, незалежно від їхньої довжини.
• New York Times: з великої літери слова від 5+ літер.

Сучасні технічні посібники зі стилю (Google, Apple, Microsoft Manual of Style) віддають перевагу Sentence case для міток інтерфейсу, основного тексту й навіть заголовків — це сприймається менш агресивно та більш розмовно.

SEO-тести (CoSchedule, Backlinko) показують, що заголовки у форматі Title Case отримують на 14-20% вищий CTR у результатах пошуку, тому використовуйте Title Case для заголовків блогів незалежно від того, якому стилю основного тексту ви віддаєте перевагу.

Кожна мова має кодифіковані конвенції або в офіційному посібнику зі стилю, або за згодою спільноти.

• JavaScript/TypeScript: змінні та функції в camelCase, класи/типи/компоненти в PascalCase, константи в CONSTANT_CASE. Згідно з посібниками Airbnb, Google та Standard.
• Python: змінні/функції/методи/модулі в snake_case, класи в PascalCase, константи в CAPS_WITH_UNDERSCORES. Вимагається стандартом PEP 8.
• Java: змінні/методи в camelCase, класи/інтерфейси в PascalCase, константи в CAPS_WITH_UNDERSCORES. Згідно з Google Java Style Guide.
• Go: MixedCaps як для експортованих (перша літера велика), так і для неекспортованих (перша літера мала) — це забезпечує gofmt.
• Rust: функції/змінні/модулі в snake_case, типи/трейти в PascalCase, константи в SCREAMING_SNAKE_CASE. Згідно з офіційним посібником зі стилю Rust.
• C#: усе публічне в PascalCase (методи, властивості, класи), параметри та приватні поля в camelCase (часто з префіксом _).
• Ruby: snake_case скрізь, за винятком класів/модулів (PascalCase) та констант (PascalCase або CAPS_WITH_UNDERSCORES).

Завжди дотримуйтеся конвенції навколишнього коду, а не нав’язуйте свій улюблений стиль.

URL-шляхи повинні бути у lower-case kebab-case з чотирьох причин.

• (1) Розділення слів у Google: дефіси сприймаються як розділювачі слів в URL, а підкреслювання — як з'єднувачі. /best-running-shoes ранжується для слів 'best', 'running', 'shoes' незалежно; /best_running_shoes розглядається як один складний термін.
• (2) Чутливість до регістру: Apache, nginx та інші сервери можуть сприймати /About та /about як різні URL за замовчуванням — це ризик штрафу за дубльований контент. Завжди використовуйте нижній регістр.
• (3) Надійність при введенні користувачем: великі літери викликають друкарські помилки; URL у нижньому регістрі легше передати усно або написати в друкованому вигляді.
• (4) Відповідність стандартам: RFC 3986 вважає шляхи чутливими до регістру, але де-факто веб-конвенцією є нижній регістр.

Найкраща практика: прибирайте діакритичні знаки (café → cafe), транслітеруйте не-ASCII символи, видаляйте артиклі для скорочення, орієнтуйтеся на 60-70 символів у шлях для оптимального SEO-відображення у SERP.

Уникайте: дат у шляхах (вказуйте їх у метаданих публікації), ідентифікаторів сесій, параметрів запитів усередині шляхів.

Акроніми — це найскладніша частина програмування конвенцій регістрів, оскільки існує два конкуруючі підходи.

• Підхід A (збереження акронімів): HTTPRequest, HTMLParser, UserID, JSONResponse, URLBuilder. Старі коди C, C++, Java 1990-2000-х років використовували це. Легше розпізнати акроніми з першого погляду.
• Підхід B (розгляд як слів): HttpRequest, HtmlParser, UserId, JsonResponse, UrlBuilder. Microsoft .NET, Google Java Style, сучасні TypeScript і JavaScript надають цьому перевагу. Легше читати назви з кількома акронімами, як-от HtmlHttpClient проти HTMLHTTPClient.

• Правило Microsoft: дволітерні акроніми залишають обидві літери великими (IOStream, IPAddress), але акроніми з трьох і більше літер стають Pascal (HtmlParser, а не HTMLParser).
• Google Java Style: завжди сприймати як слова (HtmlParser, а не HTMLParser, навіть для 3-літерного HTML).

Наш конвертер застосовує підхід B за замовчуванням. Працюючи в існуючій кодовій базі, завжди дотримуйтеся встановленого стилю — введення нової конвенції акронімів викликає непослідовність, яка тримається роками.

Різні контексти мають різні правила чутливості до регістру.

• URL: технічно чутливі до регістру (RFC 3986), але більшість вебсерверів розглядають шляхи нечутливо до регістру за замовчуванням — завжди використовуйте нижній регістр заради безпеки та SEO.
• HTML: НАЗВИ тегів та атрибутів нечутливі до регістру (DIV = div = Div), але ЗНАЧЕННЯ атрибутів чутливі до регістру (назви класів, значення ID повинні точно збігатися при посиланні з CSS/JS).
• JSON: повністю чутливий до регістру — {"userName": ...} та {"username": ...} є різними полями.
• SQL: залежить від бази даних — MySQL на Windows нечутлива до регістру для назв таблиць, MySQL на Linux чутлива; PostgreSQL переводить нецитовані ідентифікатори в нижній регістр, але зберігає цитовані; SQLite за замовчуванням нечутлива.
• Файлові системи: Windows NTFS та macOS APFS (за замовчуванням) нечутливі до регістру, але зберігають його; Linux ext4 та macOS APFS (опція чутливості до регістру) чутливі до регістру.

Git на файлових системах, нечутливих до регістру, може викликати приховані проблеми, коли співавтори на чутливих системах роблять pull. Найкраща практика: примусово встановлювати один регістр для системи через правила лінтерів, налаштування IDE або git config (core.ignorecase).

Для окремих змінних: вставте в наш конвертер, отримайте результат, вставте назад.

Для масового перейменування у файлі чи проєкті використовуйте найбезпечніший доступний інструмент.

• Рефакторинг перейменування в IDE (F2 у VS Code, Shift-F6 у JetBrains, Cmd-R-R в Xcode): найбезпечніший варіант — оновлює всі посилання, включно з імпортами, коментарями (опціонально) та динамічними рядками (часто).
• Пошук і заміна по всьому проєкту за допомогою регулярних виразів: швидше, але ризиковано — вручну перевіряйте кожну підстановку та запускайте тести після.
• Командний рядок: ripgrep з --pcre2 плюс конвеєр sed для систематичного перейменування в багатьох файлах.
• Інструменти на основі AST: jscodeshift для JavaScript/TypeScript, libcst для Python, OpenRewrite для Java — найбезпечніше для складних змін із тисячею файлів із семантичним розумінням.

Для конвертації всієї відповіді JSON API зі snake_case у camelCase використовуйте бібліотеку трансформації на межі API (camelCase-keys для Node, humps для JS, генератори псевдонімів Pydantic для Python). Ніколи не запускайте масові перейменування на брудному робочому дереві git — створіть гілку, виконайте рефакторинг, протестуйте, а потім об'єднайте.

Наївна конвертація регістрів дає збій у кількох крайніх випадках.

• (1) Акроніми — описано вище, вимагає чіткого вибору конвенції.
• (2) Цифри в ідентифікаторах — чи повинно '2024Q4Revenue' перетворитися на '2024_q4_revenue' чи '2024_q_4_revenue'? Більшість конвертерів розбивають переходи літера-цифра, але не цифра-літера; наш зберігає групи цифр.
• (3) Мапування регістрів Unicode — німецька ß переходить у нижній регістр як 'ss', а у верхній — у ẞ (офіційно 2017) або 'SS' (застаріле). Турецька i з крапкою / без крапкі має правила для конкретної локалі. Грецька кінцева сигма (ς) проти серединної (σ) не виживає при операціях зміни регістру туди й назад.
• (4) Назви брендів із внутрішніми великими літерами — iPhone, eBay, YouTube — повинні зберігатися точно, ніколи не конвертуватися. Додайте назви брендів до списку винятків регістру вашого редактора.
• (5) Ініціалізми проти акронімів — NASA є акронімом (вимовляється як слово), FBI є ініціалізмом (вимовляється як букви) — стайл-гайди трактують їх однаково, але читаються вони по-різному.
• (6) Текст змішаною мовою — конвертація символів CJK, змішаних із латиницею, не має визначеної поведінки; більшість інструментів пропускають CJK без змін.

Наш конвертер працює зі стандартним Unicode для латинських/кириличних скриптів і пропускає символи CJK; для продакшн багатомовних систем використовуйте бібліотеки на базі ICU (icu4j, PyICU) для операцій з регістром з урахуванням локалі.