Практически невозможно найти двух людей, которые отформатировали бы даже самый простой SQL-запрос одинаково. Причем каждый будет абсолютно уверен, что именно его стиль наиболее понятный и правильный. Что приводит к спорам и баталиям на code review, а самое главное к трудностям при чтении чужих запросов. Не существует и какого-нибудь большого авторитетного style-guide для SQL, какие существуют для других языков. И все решается в основном делом вкуса, о котором как известно не спорят. Возможно проблема в отсутствии теоретической основы, некого физического обоснования почему стоит придерживаться каких либо определенных правил при оформлении SQL кода. Давайте попробуем разобраться.
Примечание от переводчика:
И это ожидаемо, ввиду декларативной природы SQL. В императивных языках мы определяем и контролируем порядок выполнения операций, и это напрямую отражается на форматировании — отступы, переносы, скобки и пр. Но при написании SQL запроса мы понятия не имеем в каком порядке он будет исполняться и это лишает нас важной точки опоры. В результате мы не имеем единого принятого стиля оформления, каждый опирается на своё чувство прекрасного.
Но почти все эти разные стили (каждый из которых хорош по своему) имеют одну общую деталь. В типографике это называется "Для просмотра ссылки Войдиили Зарегистрируйся" и считается дефектом верстки. Для примера рассмотрим простой запрос. Коридор (отмечен красным) визуально разрывает наш запрос на 2 неаккуратных куска и взгляд (особенно читающего впервые) проваливается в него, теряется в соседних коридорах (прям как в Хогвартсе), тем самым отвлекая внимание от ключевых конструкций запроса и усложняя его понимание:
Но Легендарный Джо Селко в своей книге "Стиль программирования Джо Селко на SQL" предлагает пойти дальше и вытягивать SQL коридоры в вертикальные оси, что задает единую структуру всему запросу, конструктивно выделяет его отдельные части и облегчает его чтение и понимание. Рассмотрим тот же запрос, но с осью вместо коридора:
Теперь визуально весь запрос "закреплен" на оси и выглядит гораздо устойчивее. А теперь более сложный пример с подзапросами:
Здесь наш взгляд сразу наталкивается на 3 оси, а в результате и на 3 соответствующих им запроса, что позволяет достаточно быстро разобраться что этот запрос делает.
В этом посте я использую свой (наверняка не самый лучший) способ построения осей, но уверен, что вы найдете свой собственный более подходящий способ.
Примечание от переводчика:
Если я прихожу, например, на очередной Java-проект, то просто настраиваю авто форматирование в IDEA согласно внутренним или внешним стандартам кодирования, а за тем, чтобы у всех было все одинаково и понятно, следит внимательный и беспощадный Checkstyle на процессе сборки. Можно немного поспорить по поводу места открывающей фигурной скобки, однострочных if'ов для особо принципиальных, ну может быть еще несколько мелочей. Но по большому счету все более-менее уже успокоились, и в других языках и платформах дела обстоят примерно так же, но только не в SQL.
И это ожидаемо, ввиду декларативной природы SQL. В императивных языках мы определяем и контролируем порядок выполнения операций, и это напрямую отражается на форматировании — отступы, переносы, скобки и пр. Но при написании SQL запроса мы понятия не имеем в каком порядке он будет исполняться и это лишает нас важной точки опоры. В результате мы не имеем единого принятого стиля оформления, каждый опирается на своё чувство прекрасного.
Но почти все эти разные стили (каждый из которых хорош по своему) имеют одну общую деталь. В типографике это называется "Для просмотра ссылки Войди
Но Легендарный Джо Селко в своей книге "Стиль программирования Джо Селко на SQL" предлагает пойти дальше и вытягивать SQL коридоры в вертикальные оси, что задает единую структуру всему запросу, конструктивно выделяет его отдельные части и облегчает его чтение и понимание. Рассмотрим тот же запрос, но с осью вместо коридора:
Теперь визуально весь запрос "закреплен" на оси и выглядит гораздо устойчивее. А теперь более сложный пример с подзапросами:
Здесь наш взгляд сразу наталкивается на 3 оси, а в результате и на 3 соответствующих им запроса, что позволяет достаточно быстро разобраться что этот запрос делает.
В этом посте я использую свой (наверняка не самый лучший) способ построения осей, но уверен, что вы найдете свой собственный более подходящий способ.
