Convertitore di maiuscole e minuscole

• UPPERCASE converte tutte le lettere in maiuscolo (HELLO WORLD).
• lowercase converte tutte le lettere in minuscolo (hello world).
• Title Case rende maiuscola la prima lettera di ciascuna parola (Hello World).
• Sentence case rende maiuscola solo la prima lettera dell'intera frase (Hello world).
• camelCase unisce le parole senza separatori, con la prima parola in minuscolo e le successive con iniziale maiuscola (helloWorld).
• PascalCase funziona come il camelCase, ma rende maiuscola anche la prima parola (HelloWorld).
• snake_case converte tutto in minuscolo unendo le parole con trattini bassi (hello_world).
• kebab-case converte tutto in minuscolo unendo le parole con trattini (hello-world).
• CONSTANT_CASE converte tutto in maiuscolo unendo le parole con trattini bassi (HELLO_WORLD).
• dot.case converte in minuscolo unendo le parole con punti (hello.world).
• Alternating case alterna lettere maiuscole e minuscole una dopo l'altra (hElLo WoRlD).

Ogni formato applica una regola di separazione e una di capitalizzazione: la nostra calcolatrice online gestisce in automatico qualsiasi combinazione tra formato di input e di output.

Entrambi i formati uniscono le parole senza separatori. La differenza risiede nella prima lettera: il camelCase la mantiene minuscola (myVariableName), mentre il PascalCase la rende maiuscola (MyClassName).

Le convenzioni nei linguaggi moderni:

• camelCase per variabili, nomi di funzioni e nomi di metodi;
• PascalCase per nomi di classi, tipi, interfacce, enum e componenti React/Vue/Svelte.

• Esempio JavaScript: const userAccount = getCurrentUser() — userAccount e getCurrentUser sono in camelCase; class UserAccount {} — UserAccount è in PascalCase.
• Java: int totalAmount, void calculateTotal() (metodi e campi in camelCase), class Calculator (classi in PascalCase).
• C#: approccio più sfumato — proprietà e metodi pubblici sono in PascalCase (UserName, GetUserById), mentre i campi privati usano il camelCase (spesso preceduti dal prefisso _).
• TypeScript segue le convenzioni di JavaScript, aggiungendo il PascalCase per tipi e interfacce.
• I componenti React devono essere in PascalCase per essere renderizzati correttamente: i tag con nomi in minuscolo vengono interpretati come elementi HTML nativi.

Lo snake_case è la convenzione predominante nei linguaggi dinamici e di scripting.

• Python PEP 8 impone lo snake_case per nomi di funzioni, variabili, metodi, moduli e pacchetti: def calculate_total(user_id), total_amount = 0, import data_processor. Le costanti sono in MAIUSCOLO_CON_TRATTINI_BASSI (MAX_RETRY = 5). Le classi usano il PascalCase (class UserAccount).
• Ruby adotta lo snake_case ovunque — metodi, variabili, nomi di file — riservando il PascalCase o il CONSTANT_CASE alle costanti.
• SQL: lo standard di denominazione per tabelle e colonne è lo snake_case (user_accounts, created_at, last_login_date) — racchiudere gli identificatori tra virgolette conserva le maiuscole ma crea fragilità tra database diversi.
• JSON: le API generate in Python o Ruby restituiscono in genere chiavi in snake_case (API di Stripe, API di Twitter, Django REST Framework).

Nel passaggio tra backend in Python e frontend in JavaScript, scegli uno standard ed effettua la conversione al confine dell'API (ad esempio tramite un interceptor axios o generatori di alias in Pydantic).

Il kebab-case è indispensabile in tre contesti:

• (1) Nomi di classi CSS — .primary-button, .nav-link-active. Gli identificatori JavaScript non possono contenere trattini, per cui i CSS li hanno scelti proprio per evitare ogni ambiguità con il codice JS.
• (2) Slug di URL — /blog/how-to-calculate-mortgage. Google consiglia esplicitamente i trattini rispetto ai trattini bassi per separare le parole: i trattini sono interpretati come interruzioni di parola, i trattini bassi come caratteri di unione; perciò 'migliori-scarpe-corsa' viene indicizzato come tre termini distinti, mentre 'migliori_scarpe_corsa' come uno solo.
• (3) Nomi di attributi HTML — in particolare attributi data-* e nomi di custom element nei Web Components. La specifica dei Web Components impone che i nomi degli elementi personalizzati contengano un trattino (mio-componente, non mioComponente) per distinguerli dagli elementi HTML standard.

Anche le proprietà personalizzate CSS (variabili) usano il kebab-case: --primary-color, --max-width. Quando i framework CSS-in-JS trasformano i nomi delle proprietà, convertono automaticamente il camelCase di JavaScript nel kebab-case dei CSS.

Il CONSTANT_CASE (noto anche come SCREAMING_SNAKE_CASE o UPPER_SNAKE_CASE) segnala che 'questo valore non cambia mai' in quasi tutti i linguaggi di programmazione.

Casi d'uso:

• (1) Costanti a livello di linguaggio — JavaScript const PI = 3.14159, Java public static final int MAX = 100, Python ABSOLUTE_PATH = '/etc', Go const MaxRetries = 5 (sebbene Go usi spesso il MixedCase per le costanti esportate).
• (2) Valori di enumerazioni — TypeScript enum Status { PENDING, IN_PROGRESS, COMPLETED }, Java public enum Status { PENDING, IN_PROGRESS }, membri StrEnum in Python.
• (3) Variabili d'ambiente — DATABASE_URL, NODE_ENV, AWS_ACCESS_KEY_ID su ogni sistema operativo e framework.
• (4) Macro C/C++ — #define BUFFER_SIZE 1024, #define MAX_RETRY 5.
• (5) Sezioni environment nei file YAML di Docker Compose, ConfigMap di Kubernetes, secret di GitHub Actions, dashboard di Vercel e Netlify.

La visibilità del testo TUTTO_MAIUSCOLO impedisce di confondere a colpo d'occhio una costante con una variabile: è questo l'obiettivo primario della convenzione.

Il Title Case rende maiuscola la prima lettera di ogni parola; il Sentence case rende maiuscola solo la prima lettera dell'intera frase, oltre ai nomi propri.

Le varie guide di stile divergono su quali parole capitalizzare nel Title Case:

• Stile AP e APA: rendono maiuscole le parole di 4 o più lettere, NON rendono maiuscole le preposizioni brevi (in, on, at, of, by, to, for), gli articoli (a, an, the) o le congiunzioni coordinanti (and, but, or, nor) — a meno che non siano la prima o l'ultima parola.
• Chicago Manual of Style: rende maiuscole tutte le parole tranne articoli, congiunzioni coordinanti e preposizioni, a prescindere dalla lunghezza.
• New York Times: maiuscole per le parole di 5 o più lettere.

I manuali di stile tecnologici più recenti (Google, Apple, Microsoft Manual of Style) prediligono il Sentence case per etichette UI, testi ed intestazioni: risulta più colloquiale e meno aggressivo.

I test SEO (CoSchedule, Backlinko) indicano che i titoli in Title Case ottengono un CTR superiore del 14-20% nei risultati di ricerca in inglese: conviene perciò usarlo nei titoli degli articoli se il pubblico di riferimento è internazionale.

Ogni linguaggio ha formalizzato le proprie convenzioni tramite una guida di stile ufficiale o per consenso della community.

• JavaScript/TypeScript: variabili e funzioni in camelCase, classi/tipi/componenti in PascalCase, costanti in CONSTANT_CASE. Secondo le guide di stile Airbnb, Google e Standard.
• Python: variabili/funzioni/metodi/moduli in snake_case, classi in PascalCase, costanti in MAIUSCOLO_CON_TRATTINI_BASSI. Come stabilito da PEP 8.
• Java: variabili/metodi in camelCase, classi/interfacce in PascalCase, costanti in MAIUSCOLO_CON_TRATTINI_BASSI. In base alla Google Java Style Guide.
• Go: MixedCaps sia per elementi esportati (iniziale maiuscola) che non esportati (iniziale minuscola) — regola applicata da gofmt.
• Rust: snake_case per funzioni/variabili/moduli, PascalCase per tipi/trait, SCREAMING_SNAKE_CASE per costanti. Secondo la guida di stile ufficiale di Rust.
• C#: PascalCase per tutti i membri pubblici (metodi, proprietà, classi), camelCase per parametri e campi privati (spesso con prefisso _).
• Ruby: snake_case diffuso, a eccezione di classi/moduli (PascalCase) e costanti (PascalCase o MAIUSCOLO_CON_TRATTINI_BASSI).

Rispetta sempre lo stile del codice circostante anziché imporre le tue preferenze personali.

Gli slug degli URL dovrebbero essere in kebab-case minuscolo per quattro motivi.

• (1) Separazione delle parole per Google: i trattini sono interpretati come separatori di parole negli URL, mentre i trattini bassi (underscore) sono considerati elementi di unione. /best-running-shoes si posiziona separatamente per 'best', 'running' e 'shoes'; /best_running_shoes viene trattato come un unico termine composto.
• (2) Sensibilità alle maiuscole (case sensitivity): Apache, nginx e altri server potrebbero considerare /About e /about come due URL distinti per impostazione predefinita, con il rischio di penalizzazioni per contenuti duplicati. Usa sempre le minuscole.
• (3) Affidabilità nella digitazione: le lettere maiuscole aumentano il rischio di refusi; gli URL in minuscolo sono più semplici da condividere verbalmente o stampare su carta.
• (4) Conformità agli standard: l'RFC 3986 stabilisce che i percorsi sono sensibili alle maiuscole, ma la convenzione de facto del web prevede l'uso del minuscolo.

Best practice: rimuovi i segni diacritici (café → cafe), traslittera i caratteri non ASCII, elimina gli articoli (the/a/an) per accorciare il testo e punta a slug di 60-70 caratteri per una visualizzazione ottimale nella SERP a fini SEO.

Da evitare: date negli slug (gestiscile nei metadati di pubblicazione), ID di sessione e parametri di query incorporati nello slug.

Gli acronimi rappresentano l'aspetto più complesso delle convenzioni di maiuscole e minuscole nella programmazione, poiché esistono due approcci contrapposti.

• Approccio A (conservare gli acronimi): HTTPRequest, HTMLParser, UserID, JSONResponse, URLBuilder. Tipico del codice C, C++ e Java degli anni '90 e 2000. Rende più facile individuare gli acronimi a colpo d'occhio.
• Approccio B (trattarli come parole): HttpRequest, HtmlParser, UserId, JsonResponse, UrlBuilder. Scelta preferita da Microsoft .NET, Google Java Style, TypeScript moderno e JavaScript. Migliora la leggibilità nei nomi composti da più acronimi, come HtmlHttpClient rispetto a HTMLHTTPClient.

• Regola di Microsoft: gli acronimi di due lettere mantengono entrambe le lettere maiuscole (IOStream, IPAddress), mentre quelli di tre o più lettere seguono il PascalCase (HtmlParser, non HTMLParser).
• Google Java Style: vengono sempre trattati come parole (HtmlParser, non HTMLParser, anche per acronimi di tre lettere come HTML).

Il nostro convertitore applica l'Approccio B per impostazione predefinita. Quando lavori su una codebase esistente, uniformati sempre allo stile già adottato: introdurre una convenzione diversa genera incongruenze destinate a protrarsi per anni.

Contesti diversi applicano regole differenti per la distinzione tra maiuscole e minuscole.

• URL: tecnicamente sensibili alle maiuscole (RFC 3986), ma la maggior parte dei server web gestisce i percorsi senza distinzione per impostazione predefinita — usa sempre il minuscolo per sicurezza e ottimizzazione SEO.
• HTML: i NOMI di tag e attributi non fanno distinzione tra maiuscole e minuscole (DIV = div = Div), ma i VALORI degli attributi sì (i nomi delle classi e i valori degli ID devono corrispondere esattamente quando richiamati da CSS/JS).
• JSON: fa piena distinzione tra maiuscole e minuscole — {"userName": ...} e {"username": ...} sono campi distinti.
• SQL: dipende dal database — MySQL su Windows non fa distinzione per i nomi di tabella, mentre su Linux sì; PostgreSQL converte gli identificatori non delimitati da virgolette in minuscolo ma preserva quelli tra virgolette; SQLite non fa distinzione per impostazione predefinita.
• File system: Windows NTFS e macOS APFS (impostazione predefinita) non distinguono tra maiuscole e minuscole ma preservano la formattazione originale; Linux ext4 e macOS APFS (con opzione case-sensitive attiva) distinguono tra maiuscole e minuscole.

L'uso di Git su file system non sensibili alle maiuscole può causare anomalie silenziose quando altri collaboratori scaricano il codice su sistemi sensibili alle maiuscole. Best practice: applica una sola convenzione a livello di sistema tramite regole di linter, impostazioni dell'IDE o configurazione di git (core.ignorecase).

Per singole variabili: incolla il testo nel nostro convertitore, ottieni il risultato e incollalo nuovamente nel codice.

Per ridenominazioni massive all'interno di un file o progetto, impiega lo strumento più affidabile a disposizione.

• Refactoring di ridenominazione dell'IDE (F2 in VS Code, Shift-F6 in JetBrains, Cmd-R-R in Xcode): l'opzione più sicura — aggiorna tutti i riferimenti, inclusi import, commenti (opzionale) e stringhe dinamiche (spesso).
• Trova e sostituisci a livello di progetto con regex: più rapido ma rischioso — verifica manualmente ogni occorrenza ed esegui i test successivamente.
• Riga di comando: ripgrep con --pcre2 combinato con sed per ridenominazioni sistematiche su numerosi file.
• Strumenti basati su AST: jscodeshift per JavaScript/TypeScript, libcst per Python, OpenRewrite per Java — ideali per modifiche complesse su migliaia di file con comprensione semantica del codice.

Per convertire un'intera risposta API JSON da snake_case a camelCase, usa una libreria di trasformazione all'estremità dell'API (camelcase-keys per Node, humps per JS, generatori di alias in Pydantic per Python). Non eseguire mai ridenominazioni massive su un working tree git con modifiche in sospeso: crea un branch, effettua il refactoring, testa e infine procedi al merge.

Una conversione ingenua delle maiuscole e minuscole non riesce a gestire diversi casi limite.

• (1) Acronimi: descritti in precedenza, richiedono una scelta esplicita della convenzione da adottare.
• (2) Numeri negli identificatori: '2024Q4Revenue' dovrebbe diventare '2024_q4_revenue' o '2024_q_4_revenue'? La maggior parte dei convertitori separa il passaggio da lettera a cifra ma non quello da cifra a lettera; il nostro preserva i blocchi numerici.
• (3) Mappatura del case in Unicode: la ß tedesca diventa 'ss' in minuscolo, ma in maiuscolo diventa ẞ (ufficiale dal 2017) o 'SS' (standard storico). La 'i' con o senza puntino in turco segue regole specifiche per il locale. La sigma finale greca (ς) rispetto a quella mediana (σ) non mantiene la distinzione nelle conversioni bidirezionali.
• (4) Nomi di brand con maiuscole interne: iPhone, eBay, YouTube devono rimanere invariati, senza alcuna conversione. Aggiungi i marchi all'elenco delle eccezioni del tuo editor.
• (5) Sigle rispetto ad acronimi: NASA è un acronimo (letto come parola), FBI è una sigla (letta lettera per lettera); le guide di stile li gestiscono allo stesso modo, ma la lettura differisce.
• (6) Testi in lingue miste: la conversione di caratteri CJK combinati con l'alfabeto latino non segue un comportamento predefinito; la maggior parte dei programmi lascia inalterati i caratteri CJK.

Il nostro convertitore gestisce lo standard Unicode per gli alfabeti latino e cirillico e mantiene intatti i caratteri CJK; per ambienti di produzione multilingue, ricorri a librerie basate su ICU (icu4j, PyICU) per operazioni conformi al locale.