Форматтер SQL

До и после

До:

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;

После (ведущая запятая, ключевые слова в верхнем регистре, отступ 2 пробела):

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;

Стилевые решения, которые важны

• Верхний против нижнего регистра ключевых слов. UPPERCASE традиционен и легко считывается. Нижний регистр чище в современных редакторах кода с подсветкой синтаксиса.
• Ведущие против хвостовых запятых. Ведущие ( , col) упрощают комментирование одного столбца. Хвостовые (col,) читаются естественнее в тексте.
• Расположение запятых в GROUP BY. Часто по одной на строку для длинных клауз, в строку для коротких.
• Отступ JOIN. ON на следующей строке (висячий отступ) или на той же строке. Длинные условия выигрывают от висячего отступа.
• Подзапросы. Отступайте весь подзапрос, а не только открывающую скобку.

Особенности диалектов

• Обратные кавычки MySQL против двойных кавычек PostgreSQL для идентификаторов.
• CTE WITH, у MS SQL есть требование ; перед WITH; форматтер это учитывает.
• Оконные функции, длинные клаузы OVER (...) выигрывают от перенесенных по строкам PARTITION BY и ORDER BY.
• BigQuery имеет ARRAY_AGG, STRUCT и суффиксы таблиц (*_yyyymmdd), которые токенизатор не должен ломать.
• Oracle имеет синтаксис внешнего соединения (+), форматтер его сохраняет, но помечает как устаревший.

Чего форматтер не делает

• Не исправляет ошибки, некорректный JOIN остается некорректным.
• Не разворачивает SELECT *, списки столбцов не выводятся из схемы.
• Не оптимизирует запросы, только компоновка, не планы выполнения.
• Не переписывает подзапросы в CTE, это другая задача.