Guida di stile SQL: best practice di formattazione

Una guida di stile SQL è un insieme di convenzioni che rendono le query leggibili e mantengono coerenti i diff di un team. A SQL non importa: le parole chiave non distinguono maiuscole e minuscole e gli spazi vengono ignorati, quindi SELECT, select e SeLeCt vengono eseguiti tutti allo stesso modo, e una query scritta su una sola riga di 200 caratteri restituisce esattamente le stesse righe della stessa query distribuita su venti righe indentate. Lo stile, quindi, riguarda esclusivamente le persone che leggeranno la query in seguito.

Se ti serve subito una query pulita, incollala nel formattatore SQL, scegli il tuo dialetto e copia il risultato. Ma capire le regole dietro quell’output è ciò che ti permette di definire uno standard di team invece di discuterne a ogni pull request. Questa guida ti accompagna attraverso le scelte che contano: maiuscole e minuscole delle parole chiave, indentazione e a capo, denominazione, particolarità specifiche dei dialetti e come automatizzare il tutto.

Una cosa da tenere a mente lungo tutta la guida. Poiché SQL ignora gli spazi bianchi e le maiuscole, nessuna di queste regole viene imposta dal database: esistono al servizio delle persone che leggono, revisionano e mantengono la query. Questo ha due conseguenze. Primo, raramente esiste un’unica risposta “corretta”; la maggior parte di queste decisioni consiste nello scegliere una convenzione ragionevole e applicarla ovunque, e questa guida è onesta su dove stiano i veri compromessi invece di fingere che uno stile vinca in modo netto. Secondo, poiché le regole sono convenzioni e non requisiti, danno valore solo quando vengono applicate in modo coerente. Per questo quasi ogni sezione arriva allo stesso consiglio: decidi una volta, poi lascia che sia uno strumento a imporlo.

Perché la formattazione SQL conta

L’argomento più chiaro a favore della formattazione emerge nella code review. Un ORM o uno step di build spesso emette le query come un’unica riga ininterrotta:

select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=true group by u.id,u.name order by orders desc

Nessuno può revisionarla. Riformattata, la struttura è evidente e il diff è revisionabile riga per riga:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Il debug ne beneficia allo stesso modo. Quando copi una query su una sola riga da un log di slow query e ha tre join e un WHERE ingarbugliato, formattarla per prima cosa trasforma il “dov’è il bug” in una scansione di trenta secondi. Il predicato difettoso è sulla sua riga, i join sono impilati, e un prodotto cartesiano accidentale o un filtro dimenticato diventano visibili invece di restare sepolti in un muro di testo. Lo stesso trucco aiuta quando leggi SQL generato da qualche altro sistema: i query builder e gli strumenti di reportistica sono noti per produrre output corretto ma illeggibile.

La coerenza è la vittoria più silenziosa, e col tempo la più utile. Quando tutti formattano allo stesso modo, i diff mostrano solo ciò che è effettivamente cambiato, una nuova colonna o un filtro modificato, invece del rumore generato dalle preferenze di spaziatura di una persona che cozzano con quelle di un’altra. L’attenzione di chi revisiona è limitata; spenderla su spazi bianchi riposizionati è uno spreco. Una formattazione coerente rende anche più facile l’onboarding: una persona appena assunta legge query che si assomigliano tutte, impara una volta la forma del team e la applica ovunque. Niente di tutto questo richiede di formattare a mano, che è il tema della sezione finale: tu decidi le regole, uno strumento le applica.

Un invariante è alla base di tutto questo, e vale la pena enunciarlo chiaramente perché viene ripetuto in tutta questa guida: la formattazione cambia solo spazi bianchi, a capo, maiuscole e minuscole delle parole chiave e commenti. Non cambia mai la logica della query né i suoi risultati. Una query formattata è la stessa query. Ecco perché puoi tranquillamente passare la versione disordinata qui sopra attraverso il formattatore SQL senza preoccuparti di cosa restituisce.

Maiuscole e minuscole delle parole chiave: UPPERCASE vs lowercase

Il dibattito più antico in qualsiasi guida di stile SQL è se le parole chiave riservate debbano essere UPPERCASE o lowercase. Entrambe sono valide, perché SQL non distingue maiuscole e minuscole per le parole chiave. Il disaccordo riguarda la leggibilità, e vale la pena capire entrambe le posizioni prima di scegliere.

A favore delle parole chiave UPPERCASE

L’argomento tradizionale è il contrasto visivo. Scrivere SELECT, FROM, WHERE, JOIN e GROUP BY in maiuscolo fa risaltare le parole chiave rispetto ai nomi minuscoli di tabelle e colonne, così puoi scorrere la forma di una query (le sue clausole, la sua struttura) senza affidarti a un editor che le colori.

Conta più di quanto sembri, perché SQL viaggia attraverso un sacco di posti privi di evidenziazione della sintassi: file di log, thread email, descrizioni di pull request, un diff in testo semplice, un messaggio Slack, una dashboard di monitoraggio, uno stack trace. In tutti questi, le parole chiave maiuscole sono l’unica cosa che mantiene leggibile la struttura: togli l’evidenziazione e select id from users where active è una zuppa di parole minuscole, mentre SELECT id FROM users WHERE active si legge ancora come una query a colpo d’occhio. Questa è la convenzione che troverai nella maggior parte delle guide di stile più datate, nella documentazione dei database e in quasi tutti i manuali di SQL, motivo per cui anche molti sviluppatori trovano le parole chiave maiuscole più familiari, persino quando il loro editor le colorerebbe comunque.

A favore delle parole chiave lowercase

La controargomentazione moderna è che l’evidenziazione della sintassi ha risolto il problema del contrasto. Ogni editor e IDE colora le parole chiave in modo distinto, quindi metterle in maiuscolo è ridondante, e per alcuni il tutto maiuscolo suona come urlare. È anche leggermente più veloce da digitare senza raggiungere lo shift a ogni parola chiave.

Lo stile minuscolo ha un vero slancio nel mondo dell’analytics engineering. La community di dbt e diverse guide di stile di team ampiamente citate adottano le parole chiave minuscole come default, sulla logica che è l’evidenziazione a portare il peso visivo e che il minuscolo mantiene la query più calma da leggere. C’è anche un punto più sottile a loro favore: le parole chiave minuscole stanno allo stesso livello visivo dei tuoi nomi di tabelle e colonne in snake_case, così l’intera query si legge come un unico testo coerente invece di due registri (parole chiave che urlano e identificatori sommessi) che competono per l’attenzione. Se questo sia un pregio o un difetto è esattamente il genere di cosa su cui i team non sono d’accordo, il che ci porta all’unico verdetto che regge davvero.

Il verdetto: la coerenza batte la scelta

Ecco la parte che conta davvero: quale dei due scegli è molto meno importante del fatto di sceglierne uno e imporlo. Una codebase in cui metà delle query urlano SELECT e l’altra metà sussurra select è il risultato peggiore, perché l’incoerenza stessa diventa rumore. Maiuscole e minuscole miste in una singola query sono ancora peggio.

Il motivo per cui la coerenza vince è meccanico, non estetico. Le maiuscole incoerenti fanno mentire i diff: chi revisiona vede una riga “modificata” che in realtà è solo qualcuno che riformatta una parola chiave, e la modifica vera si nasconde in mezzo al rumore. Anche grep e ricerca diventano meno affidabili quando la stessa parola chiave compare in tre forme di maiuscole. Un unico stile imposto elimina tutto questo overhead al costo di una sola decisione. Quindi decidi come team, mettilo per iscritto, e lascia che sia uno strumento a imporlo invece di affidarti alla disciplina. Il formattatore SQL ha un controllo Keywords con tre opzioni (UPPERCASE, lowercase e Preserve), così puoi normalizzare un’intera pila di query storiche a un solo stile con un singolo clic. La stessa query, resa in entrambi i modi:

-- UPPERCASE
SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC;

-- lowercase
select id, email from users where active = true order by created_at desc;

Scegli quella che il tuo team preferisce. Il punto è che tutte le tue query la rispettino.

Indentazione e a capo

Le maiuscole e minuscole decidono come appaiono le parole chiave. L’indentazione e gli a capo decidono come la logica della query si proietta sulla pagina, ed è qui che risiede gran parte della leggibilità.

Lo stile “a fiume” vs lo stile a blocchi

La nota sqlstyle.guide di Simon Holywell ha reso popolare lo stile “a fiume”, in cui le parole chiave sono allineate a destra così che un canale verticale di spazio bianco scorra lungo il centro della query:

SELECT id,
       email,
       created_at
  FROM users
 WHERE active = true
 ORDER BY created_at DESC;

Il fascino sta nel fatto che SELECT, FROM e WHERE si allineano sul loro bordo destro e l’elenco delle colonne si dispone ordinatamente alla destra del fiume. Gli svantaggi sono però pratici. L’allineamento dipende dalla lunghezza della tua parola chiave più lunga, quindi aggiungere un LEFT JOIN può costringerti a re-indentare tutto; è faticoso da mantenere a mano; e produce diff rumorosi, perché cambiare la lunghezza di una parola chiave sposta lo spazio bianco sulle righe vicine.

Lo stile a blocchi (o allineato a sinistra) fa partire ogni clausola principale dal margine sinistro sulla sua riga e indenta il contenuto della clausola:

SELECT
  id,
  email,
  created_at
FROM users
WHERE active = true
ORDER BY created_at DESC;

Questo è il default mainstream e quello che la maggior parte degli strumenti produce, proprio perché è stabile: aggiungere una clausola non riflusso mai le righe sopra di essa, così i diff restano piccoli e il layout sopravvive alla formattazione automatica. Lo stile a fiume ottimizza per come appare una query finita presa isolatamente; lo stile a blocchi ottimizza per come le query cambiano nel tempo e per come si revisionano nel controllo di versione. Per tutto ciò che vive in un repository e viene modificato, lo stile a blocchi è la scommessa più sicura, ed è quello che il resto di questa guida presuppone.

Quanti spazi: 2 vs 4 vs tab

Una volta che indenti, devi decidere di quanto. Le tre risposte comuni hanno ciascuna una loro motivazione:

• 2 spazi è il default più comune. Mantiene i diff compatti ed evita che le query annidate marcino oltre il bordo destro dello schermo.
• 4 spazi dà a ogni livello di annidamento più separazione visiva, il che aiuta nelle query con sottoquery profonde o molti livelli di CTE.
• Tab lasciano che ogni sviluppatore scelga la propria larghezza di visualizzazione senza modificare il file.

Qui non esiste una risposta universalmente corretta, ed è esattamente per questo che il formattatore SQL espone un controllo Indent con tutte e tre (2 spaces, 4 spaces, Tab). Scegline uno e applicalo ovunque.

Dove andare a capo

La larghezza dell’indentazione è la parte facile. La decisione di maggior impatto è dove inserire gli a capo:

• Colonne in SELECT: una colonna per riga per qualsiasi cosa non banale, così aggiungere o rimuovere una colonna tocca esattamente una riga nel diff. Le query molto brevi possono restare su una sola riga.
• FROM e JOIN: fai partire ogni join sulla sua riga, con la condizione ON o di seguito o indentata sotto di esso. Questo mantiene leggibile il grafo dei join.
• WHERE: metti ogni AND / OR sulla sua riga così che la logica booleana si legga dall’alto verso il basso. Per condizioni miste AND/OR, racchiudi tra parentesi e indenta i gruppi così che la precedenza sia esplicita invece di qualcosa che chi legge deve ricavare.

Queste sono linee guida, non leggi. Una banale SELECT id FROM users WHERE id = 1 non ha bisogno di cinque righe, e forzarcela danneggia la leggibilità invece di aiutarla. Il giudizio è grosso modo: vai a capo quando la query ha più di una o due colonne, più di una tabella, o più di una condizione. Al di sotto di quella soglia una singola riga è più chiara; al di sopra, vai a capo con decisione. Un buon formattatore codifica per te una soglia sensata, ma vale la pena capire il principio così che l’output non ti sorprenda mai.

Applicate alla query disordinata su una riga di prima, quelle regole producono un layout in cui ogni clausola e ogni join sono visibili a colpo d’occhio:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Virgole iniziali vs finali

Una questione più piccola ma persistente: dove va la virgola in un elenco di colonne su più righe?

-- Leading commas
SELECT
    id
  , email
  , created_at
FROM users;

-- Trailing commas
SELECT
    id,
    email,
    created_at
FROM users;

Le virgole iniziali hanno un vero vantaggio: aggiungere o rimuovere una colonna cambia una sola riga, e una virgola mancante è facile da individuare perché la riga incriminata risalta. Le virgole finali si leggono in modo più naturale e sono di gran lunga più comuni nella pratica. Entrambe vanno bene: scegline una, e lascia che il formattatore la applichi così che nessuno debba pensarci di nuovo.

Convenzioni di denominazione per tabelle e colonne

La formattazione governa gli spazi bianchi; la denominazione governa gli identificatori stessi, e una guida di stile è incompleta senza di essa.

Lo standard di fatto per gli identificatori SQL è snake_case, ossia tutto minuscolo con le parole separate da underscore: user_id, created_at, order_items. Si guadagna quello status per un motivo concreto, non per semplice abitudine: gli identificatori in snake_case non hanno mai bisogno di virgolette e si comportano in modo coerente tra i dialetti, mentre camelCase (comune nel codice applicativo) entra in conflitto con il modo in cui i database normalizzano le maiuscole e minuscole, su cui torneremo tra un momento.

Vale la pena essere espliciti sul perché questo differisce dal codice applicativo. Nella maggior parte dei linguaggi di programmazione, è il codice circostante a controllare gli identificatori, e camelCase o PascalCase sono la norma. Gli identificatori SQL, al contrario, vengono interpretati dalle regole di case-folding del database stesso, e quelle regole sono proprio ciò che rende fragili i nomi a maiuscole e minuscole miste. snake_case schiva l’intero problema: non c’è nessuna maiuscola/minuscola da normalizzare, nessun motivo per usare le virgolette, e niente che si comporti diversamente da un motore all’altro.

Qualche altra convenzione che compare in quasi ogni guida di stile SQL:

• Nomi di tabella singolari vs plurali è una vera spaccatura. users (plurale, “la tabella contiene utenti”) e user (singolare, “ogni riga è un utente”) hanno entrambi sostenitori. Come per le maiuscole e minuscole, la scelta conta meno dell’applicarla in modo coerente a ogni tabella.
• Evita le parole riservate come identificatori. Chiamare una colonna order, user o table ti costringe a usare le virgolette ovunque e invita a errori confusi. Opta invece per order_id o account.
• Mantieni coerente la denominazione delle chiavi. Una chiave primaria chiamata id e chiavi esterne chiamate <referenced_table>_id (come user_id) rendono i join prevedibili e autoesplicativi.

C’è una trappola che vale la pena segnalare esplicitamente, perché morde i team che chiamano le colonne del database come chiamano le variabili applicative. In PostgreSQL, un identificatore senza virgolette viene normalizzato a minuscolo, quindi SELECT userId FROM t cerca in realtà una colonna chiamata userid. Nel momento in cui lo metti tra virgolette, "userId", il database preserva le maiuscole e minuscole e tratta "userId" e userid come due colonne diverse:

-- Crea una colonna il cui nome reale è minuscolo "userid"
CREATE TABLE t (userId integer);

-- Entrambe funzionano — il nome è stato normalizzato a minuscolo
SELECT userId FROM t;
SELECT userid FROM t;

-- Questa fallisce: "column \"userId\" does not exist"
-- Le virgolette forzano una corrispondenza esatta, sensibile alle maiuscole e minuscole
SELECT "userId" FROM t;

Nota che database diversi normalizzano le maiuscole e minuscole in direzioni diverse (Oracle normalizza gli identificatori senza virgolette a maiuscolo, diversi altri a minuscolo), quindi gli identificatori tra virgolette a maiuscole e minuscole miste non sono nemmeno portabili. La via d’uscita pulita è evitare del tutto gli identificatori tra virgolette a maiuscole e minuscole miste e attenersi a snake_case, che aggira l’intero problema e mantiene il tuo schema leggibile in ogni dialetto.

Per un confronto più approfondito tra camelCase, snake_case e kebab-case, incluso quando ciascuno sia la scelta giusta tra codice e dati, vedi la guida alle convenzioni di denominazione.

Formattazione tra dialetti SQL

Tutto ciò che precede è in gran parte indipendente dal dialetto: maiuscole e minuscole, indentazione, a capo e denominazione si applicano indipendentemente dal database che hai come obiettivo. Ma “formatta questo SQL” sbatte contro un muro nel momento in cui la tua query usa sintassi specifica di un database, perché un parser generico che non riconosce quella sintassi la storpierà: potrebbe spezzare un token nel posto sbagliato, leggere male un operatore, o trattare un carattere di quoting come delimitatore di stringa e inghiottire metà della query. È qui che la formattazione consapevole del dialetto si rivela utile, ed è il motivo per cui il formattatore ti chiede di scegliere prima un database invece di tirare a indovinare. Le differenze qui sotto sono quelle in cui ti imbatti più spesso nelle query di tutti i giorni.

Operazione	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle	Standard SQL
Concatenazione di stringhe	|| o CONCAT()	CONCAT()	+ o CONCAT()	|| o CONCAT()	||
Fallback NULL	COALESCE()	COALESCE() / IFNULL()	COALESCE() / ISNULL()	COALESCE() / NVL()	COALESCE()
Limitazione delle righe	LIMIT	LIMIT	TOP / OFFSET … FETCH	FETCH FIRST	FETCH FIRST
Quoting degli identificatori	virgolette doppie ("…")	backtick	parentesi quadre ([…])	virgolette doppie ("…")	virgolette doppie ("…")

Concatenazione di stringhe e gestione di NULL

Due delle operazioni quotidiane più comuni si scrivono in modo diverso tra i dialetti.

Concatenazione di stringhe:

-- PostgreSQL, Oracle, SQLite (standard operator)
SELECT first_name || ' ' || last_name AS full_name FROM users;

-- SQL Server (T-SQL uses +)
SELECT first_name + ' ' + last_name AS full_name FROM users;

-- Portable across dialects
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

Fallback per NULL:

-- Standard SQL (works everywhere)
SELECT COALESCE(nickname, name) AS display_name FROM users;

-- SQL Server only
SELECT ISNULL(nickname, name) AS display_name FROM users;

-- MySQL / MariaDB only
SELECT IFNULL(nickname, name) AS display_name FROM users;

Un formattatore impostato sul dialetto sbagliato potrebbe non capire ISNULL o l’operatore || e può analizzare male la query circostante.

Limitazione delle righe e quoting degli identificatori

Limitare le righe del risultato è uno dei pezzi di sintassi più divergenti tra i dialetti:

-- PostgreSQL, MySQL, SQLite
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 10;

-- SQL Server (T-SQL)
SELECT TOP 10 id, name FROM users ORDER BY created_at DESC;

-- Standard SQL / Oracle
SELECT id, name FROM users ORDER BY created_at DESC FETCH FIRST 10 ROWS ONLY;

Anche il quoting degli identificatori si divide in tre. Quando devi usare le virgolette per un identificatore (di solito per usare una parola riservata o preservare le maiuscole e minuscole), il delimitatore dipende dal database:

-- MySQL / MariaDB use backticks
SELECT `order`, `user` FROM `select`;

-- SQL Server (T-SQL) uses square brackets
SELECT [order], [user] FROM [select];

-- Standard SQL (PostgreSQL, Oracle, SQLite) uses double quotes
SELECT "order", "user" FROM "select";

Un formattatore che crede che i backtick di MySQL siano delimitatori di stringa, o che le parentesi quadre di T-SQL siano qualcos’altro, produrrà output rotto. L’impostazione del dialetto è ciò che gli dice quale è quale. Questo è anche il motivo per cui copiare e incollare una query tra database è raramente uno scambio pulito: lo stesso intento logico (concatenare due stringhe, ripiegare su NULL, limitare a dieci righe, mettere tra virgolette una parola riservata) è scritto in quattro modi diversi tra i dialetti, e solo il parser che conosce il tuo database può riformattarlo senza corromperlo.

Perché la formattazione consapevole del dialetto conta

È esattamente per questo che il formattatore SQL include nove dialetti (PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, Snowflake, Oracle, SQLite, MariaDB e Standard SQL) invece di un’unica modalità generica. Selezionare quello giusto significa che il parser gestisce correttamente le stringhe dollar-quoted e i cast :: di PostgreSQL, gli identificatori tra parentesi quadre e TOP di T-SQL, le funzioni specifiche dei warehouse in BigQuery e Snowflake, e le regole di quoting qui sopra, invece di indovinare e sbagliarle. Scegli il tuo database reale dal menu a tendina prima di formattare, e l’output torna corretto e idiomatico.

Automatizzare la formattazione SQL

Leggere le regole è una cosa; nessuno dovrebbe applicarle a mano. Il senso di una guida di stile è che sia una macchina a imporla. Ci sono tre punti in cui collegare la formattazione, a seconda di quanto attrito vuoi eliminare.

Nel tuo editor (formattazione al salvataggio)

L’opzione che richiede meno sforzo è formattare automaticamente ogni volta che salvi. VS Code ha estensioni di formattazione SQL che girano al salvataggio, e JetBrains DataGrip e gli strumenti per database in altri IDE includono un formattatore integrato che puoi associare a una scorciatoia da tastiera o a un hook di salvataggio. Una volta configurato, le tue query semplicemente non sono mai non formattate, lo stesso modello di Prettier per JavaScript o gofmt per Go. Il problema è che le impostazioni dell’editor risiedono sulla macchina di ogni sviluppatore, quindi la formattazione al salvataggio mantiene ordinato il tuo SQL ma non garantisce, da sola, che lo faccia quello del resto del team. Per questo ti serve il livello successivo.

In CI con un linter

Per imporre lo stile su tutto un team, sposta il controllo nell’integrazione continua. Un linter SQL come sqlfluff sia controlla che corregge automaticamente: codifichi le tue regole (dialetto, maiuscole e minuscole delle parole chiave, indentazione, posizione delle virgole) in un file di configurazione .sqlfluff, esegui sqlfluff lint per segnalare le violazioni e sqlfluff fix per ripararle, e fai sì che la CI bocci qualsiasi pull request che si discosta dallo stile concordato. È la stessa idea di ESLint o Prettier che fanno da gate a un repo frontend: lo stile smette di essere un commento di review che qualcuno deve ricordarsi di lasciare e diventa un controllo che passa o fallisce e che la macchina non dimentica mai. Il vantaggio è che i dibattiti sullo stile avvengono una volta, quando scrivi la configurazione, invece che a ogni pull request.

Formattazione online una tantum

A volte hai semplicemente una query brutta e nessuna voglia di installare niente: uno snippet da un log, il messaggio Slack di un collega, una query che stai incollando nella documentazione. Per questo, incollala nel formattatore SQL, scegli il dialetto, le maiuscole e minuscole e l’indentazione, e copia il risultato pulito.

Il dettaglio della privacy conta qui, ed è facile da trascurare. Molti formattatori online inviano il testo che incolli a un server per fare il lavoro, il che significa che una copia della tua query (nomi di tabelle, nomi di colonne, a volte valori letterali da un incidente in produzione) lascia la tua macchina. Il formattatore SQL gira interamente nel tuo browser, quindi il tuo SQL non viene mai caricato da nessuna parte. Questo rende sicuro formattare query che toccano schemi di produzione o logica proprietaria, che è esattamente la situazione in cui vuoi di più una formattazione pulita e di meno consegnare la tua query a una terza parte. Se nello stesso flusso di lavoro maneggi altri formati, il formattatore JSON gemello funziona allo stesso modo: stessa elaborazione nel browser, stessa copia con un clic.

I tre approcci non si escludono a vicenda, e la configurazione migliore di solito li combina: formattazione al salvataggio per il ciclo interno veloce mentre scrivi, un linter in CI come rete di sicurezza che impone lo standard del team, e un formattatore online per gli snippet usa e getta che non toccano mai il tuo repo. Qualunque tu scelga, ricorda l’invariante un’ultima volta: nessuno di questi strumenti cambia ciò che fa la tua query. Riorganizzano spazi bianchi, a capo, maiuscole e minuscole e commenti, e nient’altro.

Domande frequenti

Le parole chiave SQL dovrebbero essere maiuscole o minuscole?

Entrambe sono valide, perché le parole chiave SQL non distinguono maiuscole e minuscole. UPPERCASE fa risaltare le parole chiave in ambienti privi di evidenziazione della sintassi, come log e diff; lowercase è più facile da digitare e si adatta agli editor moderni che già colorano le parole chiave. Ciò che conta davvero è che tutto il team ne scelga una e che un formattatore la imponga: le maiuscole e minuscole miste sono la scelta peggiore.

Qual è la migliore indentazione per SQL?

Due spazi è il default più comune e mantiene i diff compatti; quattro spazi rendono più leggibili le query profondamente annidate; i tab lasciano che ogni sviluppatore scelga la propria larghezza di visualizzazione. Non c’è un’unica risposta corretta: scegline una e applicala in modo coerente in tutto il tuo team. La maggior parte dei formattatori SQL, incluso questo, supporta tutte e tre le opzioni.

Come formatto SQL automaticamente?

Ci sono tre modi per formattare SQL automaticamente: formattazione al salvataggio nel tuo editor (VS Code o DataGrip), un linter in CI come sqlfluff che corregge automaticamente lo stile, o un formattatore SQL online per l’incollaggio una tantum. La via online è la più veloce perché non richiede installazione: basta incollare, scegliere il dialetto e copiare il risultato.

Dovrei usare virgole iniziali o finali in SQL?

Le virgole iniziali (virgola all’inizio di ogni riga) danno diff più puliti quando aggiungi o rimuovi colonne e rendono facile individuare una virgola mancante; le virgole finali (virgola alla fine) si leggono in modo più naturale e sono più comuni. Entrambe sono accettabili in qualsiasi guida di stile SQL: la chiave è sceglierne una e lasciare che un formattatore la applichi automaticamente.

La formattazione di SQL cambia come viene eseguita la query?

No. La formattazione di SQL cambia solo spazi bianchi, a capo, maiuscole e minuscole delle parole chiave e commenti: non cambia mai la logica della query. Una query formattata restituisce esattamente gli stessi risultati dell’originale, motivo per cui è completamente sicuro abbellire anche le query di produzione prima di revisionarle o eseguirle.

Quale convenzione di denominazione dovrei usare per tabelle e colonne SQL?

snake_case, ossia tutto minuscolo con underscore, è lo standard di fatto per i nomi di tabelle e colonne SQL perché evita le virgolette e resta sicuro tra i dialetti. Mantieni una denominazione coerente per le chiavi primarie (id) e le chiavi esterne (user_id), ed evita di usare parole riservate come order o user come identificatori per prevenire grattacapi con le virgolette.

Come formatto SQL per un dialetto specifico come PostgreSQL o T-SQL?

Seleziona prima il dialetto corrispondente nel formattatore. La modalità PostgreSQL gestisce correttamente i cast :: e le stringhe dollar-quoted; la modalità SQL Server (T-SQL) capisce gli [identifiers] tra parentesi quadre e TOP. Scegliere il dialetto sbagliato permette a un parser generico di storpiare la sintassi specifica del dialetto, quindi imposta sempre il tuo database reale prima di formattare.

Esiste una guida di stile SQL standard?

Non esiste uno standard ufficiale, ma ne esistono diverse ampiamente citate: la sqlstyle.guide di Simon Holywell e le guide di stile pubbliche di team come Mozilla e la community di dbt. Il loro consenso condiviso (indentazione coerente, identificatori in snake_case e un a capo prima di ogni clausola principale) è ciò che questa guida codifica, e un formattatore può imporlo per te.