Convertor majuscule și minuscule

• UPPERCASE convertește fiecare literă în majusculă (HELLO WORLD).
• lowercase convertește fiecare literă în minusculă (hello world).
• Title Case pune majusculă la prima literă a fiecărui cuvânt (Hello World).
• Sentence case pune majusculă doar la prima literă a întregului șir (Hello world).
• camelCase unește cuvintele fără separator, trecând primul cuvânt în litere mici și punând majuscule la cuvintele următoare (helloWorld).
• PascalCase este identic cu camelCase, dar pune majusculă și la primul cuvânt (HelloWorld).
• snake_case trece toate literele în minuscule și le unește cu caractere de subliniere (hello_world).
• kebab-case trece toate literele în minuscule și le unește cu cratime (hello-world).
• CONSTANT_CASE trece toate literele în majuscule și le unește cu caractere de subliniere (HELLO_WORLD).
• dot.case trece în litere mici și unește cu puncte (hello.world).
• Alternating case alternează litere mari și mici literă cu literă (hElLo WoRlD).

Fiecare format include o regulă de separare și o regulă de capitalizare, iar convertorul nostru gestionează toate combinațiile de la formatul de intrare la cel de ieșire.

Ambele formate unesc cuvintele fără separator. Diferența constă în prima literă — camelCase o trece în litere mici (myVariableName), în timp ce PascalCase o scrie cu majusculă (MyClassName).

Convenția în limbajele moderne:

• camelCase pentru variabile, nume de funcții și nume de metode;
• PascalCase pentru nume de clase, tipuri, interfețe, enumerări și componente React/Vue/Svelte.

• Exemplu JavaScript: const userAccount = getCurrentUser() — userAccount și getCurrentUser sunt camelCase; class UserAccount {} — UserAccount este PascalCase;
• Java: int totalAmount, void calculateTotal() (metode/câmpuri în camelCase), class Calculator (clase în PascalCase);
• C#: mai nuanțat — proprietățile și metodele publice sunt PascalCase (UserName, GetUserById), câmpurile private folosesc camelCase (adesea cu prefixul _);
• TypeScript respectă convențiile JavaScript plus PascalCase pentru tipuri și interfețe;
• Componentele React trebuie să fie PascalCase pentru a se randa corect — etichetele cu litere mici sunt interpretate ca elemente HTML.

snake_case este convenția dominantă în limbajele dinamice și de scripting.

• Python PEP 8 impune snake_case pentru nume de funcții, variabile, metode, module, pachete: def calculate_total(user_id), total_amount = 0, import data_processor. Constantele sunt scrise cu MAJUSCULE_ȘI_LITERE_MARI (MAX_RETRY = 5). Clasele sunt PascalCase (class UserAccount);
• Ruby folosește snake_case peste tot — metode, variabile, nume de fișiere — cu constante în PascalCase sau CONSTANT_CASE;
• SQL: denumirea standard pentru tabele și coloane este snake_case (user_accounts, created_at, last_login_date) — identificatorii puși între ghilimele păstrează majusculele/minusculele, dar introduc vulnerabilități între baze de date;
• JSON: API-urile generate în Python și Ruby returnează de obicei nume de câmpuri în snake_case (API-ul Stripe, API-ul Twitter, Django REST Framework).

Când faci transformări între un backend Python și un frontend JavaScript, alege un format și fă conversia la granița API-ului (de exemplu, interceptor axios, generatori de alias Pydantic).

kebab-case este obligatoriu în trei locuri:

• (1) Nume de clase CSS — .primary-button, .nav-link-active. Identificatorii JavaScript nu pot conține cratime, așa că CSS a ales cratimele tocmai pentru a nu fi confundați cu identificatorii din JavaScript;
• (2) Slug-uri URL — /blog/cum-se-calculeaza-orele. Google recomandă în mod explicit cratimele în locul caracterelor de subliniere pentru separarea cuvintelor: cratimele sunt tratate ca pauze între cuvinte, iar caracterele de subliniere ca și conectori, așa că 'cel-mai-bun-ritm-alergare' este indexat ca trei termeni separați, în timp ce 'cel_mai_bun_ritm_alergare' este indexat ca unul singur;
• (3) Nume de atribute HTML — în special atributele data-* și numele de elemente personalizate Web Components. Specificația Web Components impune ca numele elementelor personalizate să conțină o cratimă (my-component, nu myComponent) pentru a le distinge de elementele HTML standard.

Proprietățile personalizate CSS (variabilele) folosesc de asemenea kebab-case: --primary-color, --max-width. Atunci când framework-urile CSS-in-JS transformă numele proprietăților, ele convertesc automat din camelCase (JavaScript) în kebab-case (CSS).

CONSTANT_CASE (numit și SCREAMING_SNAKE_CASE sau UPPER_SNAKE_CASE) semnalează că „această valoare nu se schimbă niciodată” în toate limbajele importante.

Cazuri de utilizare:

• (1) Constante la nivel de limbaj — JavaScript const PI = 3.14159, Java public static final int MAX = 100, Python ABSOLUTE_PATH = '/etc', Go const MaxRetries = 5 (deși Go folosește adesea MixedCase pentru constante exportate);
• (2) Valori de enumerare (Enum) — TypeScript enum Status { PENDING, IN_PROGRESS, COMPLETED }, Java public enum Status { PENDING, IN_PROGRESS }, membrii StrEnum din Python;
• (3) Variabile de mediu — DATABASE_URL, NODE_ENV, AWS_ACCESS_KEY_ID în toate sistemele de operare și framework-urile;
• (4) Macrouri C/C++ — #define BUFFER_SIZE 1024, #define MAX_RETRY 5;
• (5) Secțiuni de mediu Docker compose YAML, ConfigMaps din Kubernetes, secrete GitHub Actions, panouri de control Vercel/Netlify.

Diferența vizuală de scriere îngroșată/cu majuscule face imposibilă confundarea constantelor cu variabilele dintr-o primă aruncătură de ochi — acesta este scopul principal al convenției.

Title Case scrie cu majusculă prima literă a fiecărui cuvânt; Sentence case pune majuscule doar la prima literă a întregului enunț și la substantivele proprii.

Diferite ghiduri de stil au opinii diferite despre ce trebuie scris cu majusculă în Title Case.

• AP Style și APA: pun majuscule la cuvintele cu 4+ litere, dar NU la prepozițiile scurte (in, on, at, of, by, to, for), articole (a, an, the) sau conjuncții coordonatoare (and, but, or, nor) — cu excepția cazului în care sunt primul sau ultimul cuvânt;
• Chicago Manual of Style: pune majuscule la toate cuvintele, cu excepția articolelor, conjuncțiilor coordonatoare și prepozițiilor, indiferent de lungime;
• New York Times: majuscule pentru cuvintele cu 5+ litere.

Ghidurile de stil tehnice moderne (Google, Apple, Microsoft Manual of Style) preferă Sentence case pentru etichetele UI, textul principal și chiar titluri — se citește mai natural și are un ton mai conversațional.

Testele SEO (CoSchedule, Backlinko) arată că titlurile scrise în Title Case obțin un CTR cu 14-20% mai mare în rezultatele căutărilor, așa că folosește Title Case pentru titlurile articolelor de blog, indiferent de stilul preferat pentru corpul textului.

Fiecare limbaj are convenții codificate fie într-un ghid de stil oficial, fie prin consensul comunității.

• JavaScript/TypeScript: variabile și funcții camelCase, clase/tipuri/componente PascalCase, constante CONSTANT_CASE. Conform ghidurilor stilistice Airbnb, Google și Standard;
• Python: variabile/funcții/metode/module snake_case, clase PascalCase, constante CAPS_WITH_UNDERSCORES. Impus de PEP 8;
• Java: variabile/metode camelCase, clase/interfețe PascalCase, constante CAPS_WITH_UNDERSCORES. Conform Google Java Style Guide;
• Go: MixedCaps atât pentru elementele exportate (primă literă mare), cât și pentru cele neexportate (primă literă mică) — impus de gofmt;
• Rust: funcții/variabile/module snake_case, tipuri/trăsături PascalCase, constante SCREAMING_SNAKE_CASE. Conform ghidului oficial Rust;
• C#: PascalCase pentru tot ce este public (metode, proprietăți, clase), camelCase pentru parametri și câmpuri private (despre care se folosește adesea prefixul _);
• Ruby: snake_case peste tot, cu excepția claselor/modulelor (PascalCase) și a constantelor (PascalCase sau CAPS_WITH_UNDERSCORES).

Respectă întotdeauna convenția codului din jur, în loc să impuni stilul tău preferat.

Slugurile URL ar trebui să fie kebab-case cu litere mici din patru motive.

• (1) Separarea cuvintelor în Google: cratimele sunt tratate ca separatoare de cuvinte în URL-uri, în timp ce underscore-urile sunt tratate ca simple elemente de conectare. /best-running-shoes se clasează independent pentru 'best', 'running', 'shoes'; /best_running_shoes este tratat ca un singur termen compus.
• (2) Sensibilitatea la majuscule (case sensitivity): Apache, nginx și alte servere pot trata /About și /about ca URL-uri diferite în mod implicit — risc de penalizare pentru conținut duplicat. Folosește întotdeauna litere mici.
• (3) Fiabilitatea la tastarea de către utilizator: literele mari provoacă greșeli de tastare; URL-urile cu litere mici sunt mai ușor de partajat verbal sau de scris pe suport fizic.
• (4) Alinierea la standarde: RFC 3986 tratează căile ca fiind sensibile la majuscule și minuscule, dar convenția de facto pe web este cu litere mici.

Bune practici: elimină diacriticele (café → cafe), transliterează caracterele non-ASCII, renunță la articole (the/a/an) pentru a scurta linkul, vizează sluguri de 60-70 de caractere pentru o afișare SEO optimă în SERP.

De evitat: date în sluguri (pune-le în metadatele de publicare), ID-uri de sesiune, parametri de interogare încorporați în sluguri.

Acronimele sunt cea mai dificilă parte a convențiilor de scriere în programare, deoarece există două abordări concurente.

• Abordarea A (păstrarea acronimelor): HTTPRequest, HTMLParser, UserID, JSONResponse, URLBuilder. Codul mai vechi în C, C++, Java din anii 1990-2000 folosea această metodă. Este mai ușor să identifici acronimele dintr-o privire.
• Abordarea B (tratarea ca pe cuvinte obișnuite): HttpRequest, HtmlParser, UserId, JsonResponse, UrlBuilder. Microsoft .NET, Google Java Style, precum și TypeScript și JavaScript modern favorizează această abordare. Este mai ușor de citit nume cu acronime multiple, cum ar fi HtmlHttpClient față de HTMLHTTPClient.

• Regula Microsoft: acronimele din două litere își păstrează ambele litere majuscule (IOStream, IPAddress), dar cele de trei sau mai multe litere devin de tip Pascal (HtmlParser, nu HTMLParser).
• Stilul Java Google: tratează-le întotdeauna ca pe cuvinte (HtmlParser, nu HTMLParser, chiar și pentru HTML cu 3 litere).

Convertorul nostru aplică Abordarea B în mod implicit. Când lucrezi într-o bază de cod existentă, respectă întotdeauna stilul stabilit — introducerea unei noi convenții pentru acronime creează o inconsistență care persistă ani de zile.

Diferite contexte au reguli diferite privind sensibilitatea la majuscule și minuscule.

• URL-uri: din punct de vedere tehnic, sunt sensibile la majuscule (RFC 3986), dar majoritatea serverelor web tratează căile fără a face distincție între majuscule și minuscule în mod implicit — folosește întotdeauna litere mici pentru siguranță și SEO.
• HTML: NUMELE de etichete și atribute nu sunt sensibile la majuscule (DIV = div = Div), dar VALORILE atributelor sunt sensibile la majuscule (numele claselor, valorile ID-urilor trebuie să se potrivească exact atunci când sunt referite din CSS/JS).
• JSON: complet sensibil la majuscule — {"userName": ...} și {"username": ...} sunt câmpuri diferite.
• SQL: depinde de baza de date — MySQL pe Windows nu face distincție între majuscule și minuscule pentru numele tabelelor, MySQL pe Linux este sensibil; PostgreSQL convertește identificatorii fără ghilimele la litere mici, dar îi păstrează pe cei cu ghilimele; SQLite nu face distincție între majuscule și minuscule în mod implicit.
• Sisteme de fișiere: Windows NTFS și macOS APFS (implicit) nu sunt sensibile la majuscule, dar le păstrează; Linux ext4 și macOS APFS (opțiunea sensibilă la majuscule) sunt sensibile la majuscule.

Git pe sistemele de fișiere insensibile la majuscule poate cauza probleme silențioase atunci când colaboratorii de pe sisteme sensibile la majuscule fac pull. Cea mai bună practică: impune o singură regulă pentru majuscule per sistem prin reguli de linter, setări IDE sau configurare git (core.ignorecase).

Pentru variabile individuale: lipește în convertorul nostru, obține rezultatul, lipește înapoi.

Pentru denumiri în masă în cadrul unui fișier sau proiect, folosește cel mai sigur instrument disponibil.

• Refactoring de redenumire în IDE (F2 în VS Code, Shift-F6 în JetBrains, Cmd-R-R în Xcode): cea mai sigură opțiune — actualizează toate referințele, inclusiv importurile, comentariile (opțional) și șirurile dinamice (de multe ori).
• Căutare și înlocuire la nivelul întregului proiect cu regex: mai rapid, dar riscant — verifică manual fiecare substituție și rulează testele după aceea.
• Linie de comandă: ripgrep cu --pcre2 plus un flux sed pentru denumiri sistematice în mai multe fișiere.
• Instrumente bazate pe AST: jscodeshift pentru JavaScript/TypeScript, libcst pentru Python, OpenRewrite pentru Java — cele mai sigure pentru modificări complexe care implică mii de fișiere cu înțelegere semantică.

Pentru conversia unui răspuns complet dintr-un API JSON din snake_case în camelCase, folosește o bibliotecă de transformare la granița API-ului (camelCase-keys pentru Node, humps pentru JS, generatori de aliasuri Pydantic pentru Python). Nu rula niciodată redenumiri în masă pe un arbore de lucru git murdar — creează o ramură (branch), refactorizează, testează, apoi comasează (merge).

Conversia simplistă a literelor eșuează în câteva cazuri limită.

• (1) Acronime — tratate mai sus, necesită o alegere explicită a convenției.
• (2) Numere în identificatori — ar trebui ca '2024Q4Revenue' să devină '2024_q4_revenue' sau '2024_q_4_revenue'? Majoritatea convertoarelor despart tranzițiile literă-cifră, dar nu și cifră-literă; al nostru păstrează grupurile de cifre.
• (3) Maparea literelor Unicode — litera germană ß devine 'ss' la litere mici, dar ẞ la majuscule (oficial din 2017) sau 'SS' (moștenit). Litera i cu punct și fără punct din limba turcă are reguli specifice locale. Sigma finală grecească (ς) față de cea mediană (σ) nu supraviețuiește operațiunilor de conversie dus-întors.
• (4) Nume de mărci cu majuscule interne — iPhone, eBay, YouTube — ar trebui păstrate exact așa, fără a fi convertite vreodată. Adaugă numele mărcilor în lista de excepții a editorului tău.
• (5) Inițiale vs acronime — NASA este un acronim (pronunțat ca un cuvânt), FBI este un set de inițiale (pronunțat pe litere) — ghidurile de stil le tratează la fel, dar se citesc diferit.
• (6) Text în limbi mixte — conversia caracterelor CJK amestecate cu alfabetul latin nu are un comportament definit; majoritatea instrumentelor lasă caracterele CJK neschimbate.

Convertorul nostru gestionează Unicode standard pentru scripturile latin/chirilic și lasă caracterele CJK neschimbate; pentru sisteme multilingve de producție, folosește biblioteci bazate pe ICU (icu4j, PyICU) pentru operațiuni cu litere adaptate la specificul local.