SQL Formatting Conventions That Make Code Review Easier

SQL doesn't get the same formatting discipline as application code. There's no equivalent of Prettier running on every commit, so queries drift toward whatever shape the last person who touched them left it in — inconsistent keyword casing, inconsistent indentation, joins that wrap differently from file to file.

The convention worth adopting first is picking one keyword case for the whole codebase and sticking to it. It doesn't matter much whether it's uppercase `SELECT` or lowercase `select` — what matters is that a reviewer's eye doesn't have to re-parse casing on every query to find the actual logic.

The second is consistent indentation on joins and conditions, so a query with four joins reads as four aligned lines instead of a wall of text. This is the single biggest readability lever for anything beyond a trivial query.

The third, and the one people skip most, is reformatting a query in its own commit when you're about to make a substantive change to it. A diff that mixes formatting and logic changes is much harder to review than two diffs, even though it's more commits.