===== Rules ===== These rules aim to improve the readability and maintainability of code by ensuring that aliases are used correctly and consistently throughout the project. .. _aliasing-rules: ---------------- Aliasing Rules ---------------- Aliasing rules are guidelines that help developers avoid common pitfalls when using aliases in SQL queries. They typically focus on the use of aliases for tables, columns, and expressions, helping developers avoid ambiguity and confusion in their queries. .. toctree:: :maxdepth: 1 Rule: Always Use Implicit Aliases When Referencing Tables Rule: Do Not Use Explicit Aliasing (`AS`) When Aliasing Columns Rule: All Columns Should Have a Table Alias Rule: Tables Must Use an Alias Rule: Column Names in the Query Should Be Unique Rule: Avoid Self-Aliasing Columns .. _ambiguous-rules: ---------------- Ambiguous Rules ---------------- Ambiguous rules are guidelines that help developers avoid ambiguity and improve the clarity of their SQL queries. They typically focus on naming conventions, column references, and query structure, helping developers create more readable and maintainable code. .. toctree:: :maxdepth: 1 Rule: Do Not Use `DISTINCT` with `GROUP BY` Rule: Avoid Using `select *` .. _capitalisation-rules: -------------------- Capitalisation Rules -------------------- Capitalisation rules are guidelines that help developers maintain consistent casing in their SQL queries. They typically focus on the capitalisation of keywords, identifiers, and literals, helping developers create more readable and uniform code. .. toctree:: :maxdepth: 1 Rule: Use Lowercase for Literal `null`/`true`/`false` Values .. _convention-rules: ---------------- Convention Rules ---------------- Convention rules are guidelines that enforce consistent practices and coding patterns across a project. They typically focus on the structure, style, and efficiency of code, helping developers avoid anti-patterns and ensure that the project follows uniform conventions. By applying convention rules, teams can create a more collaborative and coherent development environment where code is predictable, easier to review, and less error-prone. .. toctree:: :maxdepth: 1 Rule: Use `!=` Not `<>` Rule: Use COALESCE Instead of IFNULL or NVL Rule: Use `count(1)` to Express “Count Number of Rows” Rule: Comparisons with `NULL` Should Use `IS` or `IS NOT` Rule: Use LEFT join Instead of RIGHT join Rule: Use Spaces for Indentation, Not Tabs .. _layout-rules: ------------ Layout Rules ------------ Layout rules are guidelines that help developers maintain a consistent and readable structure in their SQL queries. They typically focus on indentation, spacing, and alignment, helping developers create code that is easier to understand and maintain. .. toctree:: :maxdepth: 1 Rule: Delete Trailing Whitespace Rule: Place Commas at the End of the Line Rule: Function Names Must Be Immediately Followed by Parentheses Rule: Select Targets Should Be on Separate Lines Rule: select Modifiers Must Be on the Same Line as select Rule: UNION Operators Should Be Surrounded by Newlines Rule: SQL Files Must End with a Single Trailing Newline Rule: SQL Files Must Not Begin with Newlines or Whitespace Rule: Align Equal (`=`) Sign in Comparison Blocks .. _structure-rules: --------------- Structure Rules --------------- Structure rules are guidelines that help developers maintain a consistent and logical structure in their SQL queries. They typically focus on the organization of code, the use of control flow statements, and the handling of exceptions, helping developers create code that is easier to follow and debug. .. toctree:: :maxdepth: 1 Rule: Do Not Specify Redundant `ELSE NULL` in a `CASE WHEN` Statement Rule: Specify Join Keys Instead of Using `USING` Rule: Do Not Use `DISTINCT` with Parentheses