Style Guide Rule Mapping

How holywell maps to the Simon Holywell SQL Style Guide.

Enforced Rules

These rules are automatically applied by holywell on every format.

RuleDescription
Right-aligned keywordsClause keywords (SELECT, FROM, WHERE, AND, OR, etc.) are right-aligned to a per-statement river derived from the widest aligned keyword in that statement
Uppercase keywordsAll SQL reserved words and function keywords are uppercased (SELECT, FROM, WHERE, INSERT, COALESCE, NULLIF, EXTRACT, CAST, COUNT, SUM, etc.)
Boolean and NULL literalsTRUE, FALSE, and NULL are uppercased, treated as keywords
Identifier normalizationALL-CAPS unquoted identifiers are lowercased (e.g., MYTABLE becomes mytable); mixed-case identifiers like MyColumn are preserved; quoted identifiers are unchanged. Exception: projection aliases (column aliases in SELECT) are never lowercased, so SELECT id AS TOTAL keeps TOTAL as-is
Trailing commasWhen column lists wrap to multiple lines, commas are placed in trailing position (end of line) rather than leading position; continuation lines are aligned with the first item after the keyword
No trailing whitespaceAll trailing whitespace is stripped from every line
Consistent indentationContinuation lines, subexpressions, and nested blocks are indented relative to the river
JOIN formattingBare JOIN is right-aligned to the river alongside FROM; modified joins (INNER JOIN, LEFT JOIN, CROSS JOIN, etc.) are indented past the river; ON and USING clauses are indented under their join
Subquery indentationSubqueries are formatted with their own derived river width
CTE formattingWITH / AS blocks are formatted with aligned clause keywords inside each CTE body
CASE expression formattingWHEN/THEN/ELSE/END are consistently indented within CASE blocks
Semicolon terminationEvery statement is terminated with a semicolon; missing semicolons are added
Deterministic and idempotentFormatting the same input always produces the same output; formatting already-formatted output produces no changes

Partially Supported Rules

These rules are addressed but may not cover all edge cases.

RuleDescriptionNotes
Operator spacingSpaces around comparison and arithmetic operators (=, <>, +, -, etc.)Handled for most operators; some dialect-specific operators (e.g., PostgreSQL @>, `?
Line lengthLong expressions are wrapped to respect maxLineLength (default: 80)Wrapping uses heuristics; very long single tokens may exceed the configured width
Alignment of VALUESINSERT ... VALUES rows are formatted with alignmentMulti-row VALUES lists are formatted but column alignment across rows is not guaranteed

Not Enforced

These guidelines from sqlstyle.guide are not enforced by holywell because they involve semantic or naming decisions that a formatter cannot reliably make.

RuleDescriptionReason
Avoid SELECT *Use explicit column listsSemantic decision; the formatter preserves SELECT * as-is
Table/column naming conventionsAvoid abbreviations, use snake_case, avoid reserved words as namesNaming is a design decision, not a formatting concern
Correlation name rulesUse first letters of table name, avoid AS for column aliasesNaming convention; holywell preserves user-chosen aliases
Uniform suffixesUse _id, _status, _date, etc.Schema design convention
Query structure guidelinesAvoid vendor-specific syntax, use ANSI joinsholywell formats whatever syntax is used, including vendor extensions

Intentional Deviations

holywell makes a small number of deliberate choices that differ from or extend sqlstyle.guide:

Deviationholywell behaviorRationale
River width is per-statementEach statement derives its own river width from its longest aligned keyword rather than using a fixed columnProduces tighter output for simple queries while accommodating wide keywords like RETURNING in DML
Keyword uppercasing scopeholywell uppercases all recognized SQL keywords, including function-like keywords (COALESCE, NULLIF, EXTRACT, CAST, COUNT, etc.) and aggregate functions (SUM, AVG, MAX, MIN)Consistent treatment of all reserved words