Konwerter wielkości liter

• UPPERCASE zamienia wszystkie litery na wielkie (HELLO WORLD).
• lowercase zamienia wszystkie litery na małe (hello world).
• Title Case zamienia pierwszą literę każdego słowa na wielką (Hello World).
• Sentence case zamienia na wielką tylko pierwszą literę całego ciągu (Hello world).
• camelCase łączy słowa bez separatora, zapisując pierwsze słowo małą literą, a kolejne wielką (helloWorld).
• PascalCase działa tak samo jak camelCase, ale pierwsze słowo również zaczyna wielką literą (HelloWorld).
• snake_case zmienia wszystkie litery na małe i łączy je podkreśleniami (hello_world).
• kebab-case zmienia wszystkie litery na małe i łączy je myślnikami (hello-world).
• CONSTANT_CASE zmienia wszystkie litery na wielkie i łączy je podkreśleniami (HELLO_WORLD).
• dot.case zmienia na małe litery i łączy kropkami (hello.world).
• Alternating case naprzemiennie zmienia wielkość liter (hElLo WoRlD).

Każdy format koduje zarówno regułę separatora, jak i zasadę wielkości liter, a nasz konwerter obsługuje wszystkie kombinacje formatów wejściowych i wyjściowych.

Oba formaty łączą słowa bez żadnego separatora. Różnica tkwi w pierwszej literze — camelCase zapisuje ją małą literą (myVariableName), a PascalCase wielką (MyClassName).

Konwencje w nowoczesnych językach programowania:

• camelCase dla zmiennych, nazw funkcji oraz metod;
• PascalCase dla nazw klas, typów, interfejsów, wyliczeń (enum) oraz komponentów React/Vue/Svelte.

• Przykład w JavaScript: const userAccount = getCurrentUser() — userAccount i getCurrentUser to camelCase; class UserAccount {} — UserAccount to PascalCase.
• Java: int totalAmount, void calculateTotal() (metody/pola w camelCase), class Calculator (klasy w PascalCase).
• C#: bardziej zróżnicowane — publiczne właściwości i metody są w formacie PascalCase (UserName, GetUserById), a pola prywatne używają camelCase (często z przedrostkiem _).
• TypeScript przestrzega konwencji języka JavaScript oraz stosuje PascalCase dla typów i interfejsów.
• Komponenty React muszą być pisane w formacie PascalCase, aby poprawnie się renderować — małe litery w nazwach znaczników są traktowane jako elementy HTML.

snake_case to dominująca konwencja w językach dynamicznych i skryptowych.

• Python PEP 8 nakazuje stosowanie snake_case dla nazw funkcji, zmiennych, metod, modułów i pakietów: def calculate_total(user_id), total_amount = 0, import data_processor. Stałe pisane są wielkimi literami z podkreśleniami (MAX_RETRY = 5). Klasy mają format PascalCase (class UserAccount).
• Ruby używa snake_case wszędzie — w metodach, zmiennych i nazwach plików — podczas gdy stałe zapisuje w formacie PascalCase lub CONSTANT_CASE.
• SQL: standardowe nazewnictwo tabel i kolumn to snake_case (user_accounts, created_at, last_login_date) — cytowane identyfikatory zachowują wielkość liter, ale wprowadzają podatność na błędy między różnymi bazami danych.
• JSON: interfejsy API generowane w Pythonie i Ruby zazwyczaj zwracają pola w formacie snake_case (Stripe API, Twitter API, Django REST Framework).

Podczas przekształcania danych między zapleczem w Pythonie a interfejsem w JavaScript wybierz jedną konwencję i dokonaj konwersji na granicy API (np. za pomocą interceptora axios lub generatorów aliasów Pydantic).

kebab-case jest wymagany w trzech miejscach:

• (1) Nazwy klas CSS — .primary-button, .nav-link-active. Identyfikatory w języku JavaScript nie mogą zawierać myślników, dlatego w CSS wybrano myślniki celowo, aby unikać pomylenia ich z identyfikatorami JavaScript.
• (2) Przyjazne adresy URL (slugi) — /blog/how-to-calculate-mortgage. Google wyraźnie zaleca stosowanie myślników zamiast podkreśleń do oddzielania słów: myślniki są traktowane jako przerwy między słowami, a podkreślenia jako łączniki, więc 'best-running-shoes' jest indeksowane jako trzy oddzielne terminy, podczas gdy 'best_running_shoes' jako jeden.
• (3) Nazwy atrybutów HTML — w szczególności atrybuty typu data-* oraz nazwy niestandardowych elementów Web Components. Specyfikacja Web Components wymaga, aby nazwy elementów niestandardowych zawierały myślnik (my-component, a nie myComponent), co odróżnia je od standardowych elementów HTML.

Właściwości niestandardowe CSS (zmienne) również wykorzystują kebab-case: --primary-color, --max-width. Gdy frameworki CSS-in-JS przekształcają nazwy właściwości, automatycznie zmieniają zapis camelCase z JavaScriptu na kebab-case w CSS.

CONSTANT_CASE (nazywany również SCREAMING_SNAKE_CASE lub UPPER_SNAKE_CASE) we wszystkich głównych językach sygnalizuje, że „ta wartość nigdy się nie zmienia”.

Zastosowania:

• (1) Stałe na poziomie języka — JavaScript const PI = 3.14159, Java public static final int MAX = 100, Python ABSOLUTE_PATH = '/etc', Go const MaxRetries = 5 (choć Go często używa formatu MixedCase dla eksportowanych stałych).
• (2) Wartości wyliczeniowe (enum) — TypeScript enum Status { PENDING, IN_PROGRESS, COMPLETED }, Java public enum Status { PENDING, IN_PROGRESS }, elementy StrEnum w Pythonie.
• (3) Zmienne środowiskowe — DATABASE_URL, NODE_ENV, AWS_ACCESS_KEY_ID we wszystkich systemach operacyjnych i frameworkach.
• (4) Makra w C/C++ — #define BUFFER_SIZE 1024, #define MAX_RETRY 5.
• (5) Sekcje środowiskowe w plikach Docker Compose YAML, obiekty ConfigMaps w Kubernetes, sekrety w GitHub Actions oraz panele Vercel/Netlify.

Wizualne odróżnienie wielkimi literami uniemożliwia pomylenie stałej ze zwykłą zmienną na pierwszy rzut oka — i o to właśnie chodzi w tej konwencji.

Title Case zapisuje wielką literą pierwszą literę każdego słowa; Sentence case zamienia na wielką jedynie pierwszą literę całego wyrażenia oraz nazw własnych.

Różne przewodniki stylów różnią się w kwestii tego, które słowa należy pisać wielką literą w formacie Title Case.

• Styl AP i APA: pisz wielką literą słowa składające się z 4 lub więcej liter, NIE pisz wielką literą krótkich przyimków (in, on, at, of, by, to, for), artykułów (a, an, the) ani spójników współrzędnych (and, but, or, nor) — chyba że są pierwszym lub ostatnim słowem.
• Chicago Manual of Style: zapisuj wielką literą wszystkie słowa z wyjątkiem artykułów, spójników współrzędnych i przyimków, niezależnie od ich długości.
• New York Times: wielkie litery dla słów składających się z 5 lub więcej liter.

Nowoczesne przewodniki techniczne (Google, Apple, Microsoft Manual of Style) wolą format Sentence case dla etykiet interfejsu, treści akapitów, a nawet nagłówków — sprawia on wrażenie mniej krzyczącego i bardziej konwersacyjnego.

Testy SEO (CoSchedule, Backlinko) pokazują, że tytuły w formacie Title Case uzyskują o 14-20% wyższy wskaźnik klikalności (CTR) w wynikach wyszukiwania, dlatego warto stosować Title Case w nagłówkach artykułów na blogu bez względu na preferowany styl treści.

Każdy język ma skodyfikowane konwencje zapisane w oficjalnym przewodniku stylu lub ustalone przez konsensus społeczności.

• JavaScript/TypeScript: zmienne i funkcje w camelCase, klasy/typy/komponenty w PascalCase, stałe w CONSTANT_CASE. Zgodnie z przewodnikami Airbnb, Google i Standard.
• Python: zmienne/funkcje/metody/moduły w snake_case, klasy w PascalCase, stałe CAPS_WITH_UNDERSCORES. Wymagane przez standard PEP 8.
• Java: zmienne/metody w camelCase, klasy/interfejsy w PascalCase, stałe CAPS_WITH_UNDERSCORES. Zgodnie z Google Java Style Guide.
• Go: MixedCaps zarówno dla elementów eksportowanych (pierwsza litera wielka), jak i nieeksportowanych (pierwsza litera mała) — wymuszane przez narzędzie gofmt.
• Rust: funkcje/zmienne/moduły w snake_case, typy/cechy (traits) w PascalCase, stałe w SCREAMING_SNAKE_CASE. Zgodnie z oficjalnym przewodnikiem stylu języka Rust.
• C#: PascalCase dla wszystkich elementów publicznych (metody, właściwości, klasy), camelCase dla parametrów i pól prywatnych (często z przedrostkiem _).
• Ruby: snake_case w całym kodzie, z wyjątkiem klas/modułów (PascalCase) oraz stałych (PascalCase lub CAPS_WITH_UNDERSCORES).

Zawsze dopasowuj się do konwencji panującej w otaczającym kodzie, zamiast narzucać swój własny ulubiony styl.

Slugi adresów URL powinny być pisane małymi literami w formacie kebab-case z czterech powodów.

• (1) Oddzielanie wyrazów przez Google: łączniki są traktowane w adresach URL jako separator słów, a podkreślenia jako łączniki. /best-running-shoes pozycjonuje się na frazy 'best', 'running', 'shoes' niezależnie; /best_running_shoes jest traktowane jako jeden połączony termin.
• (2) Wielkość liter: Apache, nginx i inne serwery mogą domyślnie traktować /About i /about jako różne adresy URL — ryzyko kary za duplikację treści. Zawsze używaj małych liter.
• (3) Niezawodność przy wpisywaniu przez użytkownika: wielkie litery powodują literówki; adresy URL pisane małymi literami łatwiej przekazać ustnie lub zapisać w druku.
• (4) Zgodność ze standardami: RFC 3986 traktuje ścieżki z uwzględnieniem wielkości liter, ale de facto konwencją internetową są małe litery.

Najlepsza praktyka: usuwaj znaki diakrytyczne (café → cafe), transliteruj znaki spoza alfabetu ASCII, pomijaj przedimki (the/a/an) w celu skrócenia, celuj w slug o długości 60-70 znaków dla optymalnego wyświetlania SEO w wynikach wyszukiwania.

Unikaj: dat w slugach (umieszczaj je w metadanych publikacji), identyfikatorów sesji, parametrów zapytań osadzonych w slugach.

Akronimy to najtrudniejsza część programistycznych konwencji wielkości liter, ponieważ istnieją dwa konkurujące ze sobą podejścia.

• Podejście A (zachowanie akronimów): HTTPRequest, HTMLParser, UserID, JSONResponse, URLBuilder. Starszy kod w C, C++, Java z lat 90. i 2000. tak robił. Łatwiej zauważyć akronimy na pierwszy rzut oka.
• Podejście B (traktowanie jako słowa): HttpRequest, HtmlParser, UserId, JsonResponse, UrlBuilder. Microsoft .NET, Google Java Style, nowoczesny TypeScript i JavaScript preferują to podejście. Łatwiej czytać nazwy z wieloma akronimami, np. HtmlHttpClient kontra HTMLHTTPClient.

• Zasada Microsoftu: dwuliterowe akronimy zachowują obie wielkie litery (IOStream, IPAddress), ale akronimy trzy- i więcej literowe stają się zapisane w formacie Pascal (HtmlParser, a nie HTMLParser).
• Google Java Style: zawsze traktuj jak słowa (HtmlParser, a nie HTMLParser, nawet w przypadku 3-literowego HTML).

Nasz konwerter domyślnie stosuje Podejście B. Podczas pracy w istniejącej bazie kodu zawsze dopasowuj się do ustalonego stylu — wprowadzanie nowej konwencji akronimów powoduje niespójność, która utrzymuje się przez lata.

Różne konteksty mają różne zasady dotyczące wielkości liter.

• Adresy URL: technicznie uwzględniają wielkość liter (RFC 3986), ale większość serwerów WWW domyślnie traktuje ścieżki bez uwzględniania wielkości liter — zawsze używaj małych liter ze względów bezpieczeństwa i SEO.
• HTML: NAZWY znaczników i atrybutów nie uwzględniają wielkości liter (DIV = div = Div), ale WARTOŚCI atrybutów uwzględniają wielkość liter (nazwy klas, wartości identyfikatorów muszą pasować dokładnie podczas odwoływania się z CSS/JS).
• JSON: w pełni uwzględnia wielkość liter — {"userName": ...} i {"username": ...} to różne pola.
• SQL: zależy od bazy danych — MySQL w systemie Windows nie uwzględnia wielkości liter dla nazw tabel, MySQL w systemie Linux je uwzględnia; PostgreSQL zamienia nieujednoznacznione identyfikatorów na małe litery, ale zachowuje te w cudzysłowach; SQLite domyślnie nie uwzględnia wielkości liter.
• Systemy plików: Windows NTFS i macOS APFS (domyślnie) nie uwzględniają wielkości liter, ale zachowują ich wielkość; Linux ext4 i macOS APFS (opcja uwzględniająca wielkość liter) uwzględniają wielkość liter.

Git w systemach plików nierozróżniających wielkości liter może powodować ciche problemy, gdy współpracownicy w systemach rozróżniających wielkość liter robią pull. Najlepsza praktyka: wymuszaj jedną wielkość liter na system za pomocą reguł lintera, ustawień IDE lub konfiguracji gita (core.ignorecase).

Dla pojedynczych zmiennych: wklej do naszego konwertera, pobierz wynik, wklej z powrotem.

Do masowych zmian nazw w pliku lub projekcie użyj najbezpieczniejszego dostępnego narzędzia.

• Refaktoryzacja zmiany nazwy w IDE (F2 w VS Code, Shift-F6 w JetBrains, Cmd-R-R w Xcode): najbezpieczniejsza opcja — aktualizuje wszystkie odwołania, w tym importy, komentarze (opcjonalnie) i ciągi dynamiczne (często).
• Wyszukiwanie i zamiana w całym projekcie za pomocą wyrażeń regularnych: szybsze, ale ryzykowne — ręcznie zweryfikuj każde podstawienie i uruchom testy po wszystkim.
• Wiersz poleceń: ripgrep z --pcre2 plus potok sed do systematycznych zmian nazw w wielu plikach.
• Narzędzia oparte na AST: jscodeshift dla JavaScript/TypeScript, libcst dla Python, OpenRewrite dla Java — najbezpieczniejsze dla złożonych zmian obejmujących tysiące plików z rozumieniem semantycznym.

Do konwersji całej odpowiedzi API JSON ze snake_case na camelCase użyj biblioteki transformacji na granicy API (camelCase-keys dla Node, humps dla JS, generatory aliasów Pydantic dla Pythona). Nigdy nie wykonuj masowych zmian nazw w brudnym drzewie roboczym gita — utwórz gałąź, zrefaktoryzuj, przetestuj, a następnie scal.

Naiwna konwersja wielkości liter zawodzi w kilku przypadkach brzegowych.

• (1) Akronimy — omówione powyżej, wymagają wyraźnego wyboru konwencji.
• (2) Liczby w identyfikatorach — czy '2024Q4Revenue' powinno stać się '2024_q4_revenue' czy '2024_q_4_revenue'? Większość konwerterów dzieli przejścia litera-cyfra, ale nie cyfra-litera; nasz zachowuje grupy cyfr.
• (3) Mapowanie wielkości liter w Unicode — niemiecka litera ß na małą to 'ss', ale na wielką to ẞ (oficjalnie od 2017 r.) lub 'SS' (starsze wersje). Tureckie kropkowane i bezkropkowe i ma zasady specyficzne dla lokalizacji. Grecka końcowa sigma (ς) kontra medialna (σ) nie przetrwa operacji zmiany wielkości liter w obie strony.
• (4) Nazwy marek z wewnętrzną wielką literą — iPhone, eBay, YouTube — powinny być zachowane dokładnie w oryginale, nigdy niekonwertowane. Dodaj nazwy marek do listy wyjątków wielkości liter w swoim edytorze.
• (5) Inicjałowce kontra akronimy — NASA to akronim (wymawiany jak słowo), FBI to inicjałowców (wymawiany jako litery) — przewodniki stylu traktują je identycznie, ale czyta się je inaczej.
• (6) Tekst wielojęzyczny — konwersja znaków CJK zmieszanych z alfabetem łacińskim nie ma określonego zachowania; większość narzędzi przepuszcza znaki CJK bez zmian.

Nasz konwerter obsługuje standardowy Unicode dla skryptów łacińskich/cyrylickich i przepuszcza znaki CJK; w produkcyjnych systemach wielojęzycznych używaj bibliotek opartych na ICU (icu4j, PyICU) do operacji na wielkości liter uwzględniających lokalizację.