Formatter SQL

Prima e dopo

Prima:

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.created_at>='2024-01-01' GROUP BY u.id,u.name HAVING COUNT(o.id)>5 ORDER BY orders DESC LIMIT 50;

Dopo (virgola iniziale, parole chiave maiuscole, indentazione di 2 spazi):

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.created_at >= '2024-01-01'
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 5
ORDER BY orders DESC
LIMIT 50;

Scelte di stile che contano

• Parole chiave maiuscole vs minuscole. MAIUSCOLE è tradizionale e facilmente leggibile. Minuscole è più pulita nei moderni editor di codice con evidenziazione della sintassi.
• Virgole iniziali vs finali. Iniziali ( , col) rendono più facile commentare una singola colonna. Finali (col,) si leggono più naturalmente nel testo.
• Posizione delle virgole in GROUP BY. Spesso una per riga per clausole lunghe, inline per quelle brevi.
• Indentazione JOIN. ON sulla riga successiva (indentazione sospesa) vs sulla stessa riga. Condizioni lunghe beneficiano dell’indentazione sospesa.
• Sottoquery. Indenta l’intera sottoquery, non solo la parentesi di apertura.

Problemi specifici del dialetto

• Backticks MySQL vs doppi apici PostgreSQL per identificatori.
• CTE WITH, MS SQL ha un requisito di ; prima di WITH; il formatter lo gestisce.
• Funzioni di finestra, lunghe clausole OVER (...) beneficiano di PARTITION BY e ORDER BY a capo.
• BigQuery ha ARRAY_AGG, STRUCT e suffissi di tabella (*_yyyymmdd) che il tokenizer non deve interrompere.
• Oracle ha la sintassi di outer join (+), il formatter la preserva ma la segnala come legacy.

Cosa non fa il formatter

• Correggere bug, un JOIN non valido rimane non valido.
• Espandere SELECT *, le liste di colonne non vengono dedotte dallo schema.
• Ottimizzare le query, solo layout, non piani di esecuzione.
• Riscrivere sottoquery come CTE, una preoccupazione diversa.