SQL Formatting, Code Diff, and HTML Minification: Best Practices for Code Quality

Why Code Formatting Matters More Than You Think

Code formatting might seem like a cosmetic concern, but it has a measurable impact on productivity, bug rates, and team collaboration. Studies consistently show that consistently formatted code is easier to read, review, and debug. When SQL queries are properly indented, code diffs are clean and focused, and HTML is optimised for delivery, the entire development lifecycle runs more smoothly.

This guide covers three essential code quality practices: SQL formatting for readable and maintainable queries, code diffing strategies for effective reviews, and HTML minification for optimal web performance. Together, they form a foundation of professional code hygiene.

SQL Formatting: Rules for Readable Queries

SQL is one of the most widely used programming languages in the world, yet it is also one of the most inconsistently formatted. A complex query written as a single line is nearly impossible to review or debug. Proper formatting transforms SQL into something that reads almost like structured English.

Core Formatting Rules

• Uppercase keywords: Use uppercase for SQL keywords (SELECT,FROM, WHERE, JOIN) and lowercase for identifiers (table and column names). This creates an immediate visual distinction between SQL syntax and your data model.
• One clause per line: Place each major clause (SELECT, FROM,WHERE, GROUP BY, ORDER BY) on its own line.
• Indent consistently: Use 2 or 4 spaces for indentation. Indent column lists, join conditions, and subqueries one level deeper than their parent clause.
• Align JOIN conditions: Place each JOIN on its own line and indent theON clause beneath it.
• Comma placement: Either leading commas (easier to comment out lines) or trailing commas (more natural to read) — pick one and be consistent across your team.

-- ❌ Before: unformatted SQL
SELECT u.id, u.name, u.email, o.total, o.created_at FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.status = 'completed' AND o.created_at >= '2024-01-01' GROUP BY u.id, u.name, u.email, o.total, o.created_at ORDER BY o.created_at DESC LIMIT 50;

-- ✅ After: properly formatted SQL
SELECT
  u.id,
  u.name,
  u.email,
  o.total,
  o.created_at
FROM users u
INNER JOIN orders o
  ON u.id = o.user_id
WHERE
  o.status = 'completed'
  AND o.created_at >= '2024-01-01'
GROUP BY
  u.id,
  u.name,
  u.email,
  o.total,
  o.created_at
ORDER BY o.created_at DESC
LIMIT 50;

Subquery and CTE Formatting

Complex queries with subqueries or Common Table Expressions (CTEs) benefit especially from clear formatting. CTEs, in particular, can make deeply nested subqueries much more readable:

-- Using a CTE for clarity
WITH active_users AS (
  SELECT
    id,
    name,
    email
  FROM users
  WHERE status = 'active'
    AND last_login >= '2024-01-01'
),
recent_orders AS (
  SELECT
    user_id,
    SUM(total) AS total_spent,
    COUNT(*) AS order_count
  FROM orders
  WHERE created_at >= '2024-01-01'
  GROUP BY user_id
)
SELECT
  au.name,
  au.email,
  ro.total_spent,
  ro.order_count
FROM active_users au
INNER JOIN recent_orders ro
  ON au.id = ro.user_id
ORDER BY ro.total_spent DESC;

Code Diff Strategies for Effective Reviews

Code diffs — the comparison of two versions of a file — are the foundation of code review, version control, and debugging. The way you view and generate diffs has a significant impact on review quality.

Unified vs. Side-by-Side Diffs

# Generate a unified diff
diff -u old_file.sql new_file.sql

# Git unified diff with context
git diff --unified=5 HEAD~1

# Side-by-side diff in the terminal
diff --side-by-side --width=120 old.sql new.sql

Best Practices for Clean Diffs

• Separate formatting changes from logic changes: If you're reformatting a file and changing behaviour, do it in separate commits. A combined commit makes it nearly impossible to review the actual logic changes.
• Use consistent line endings: Mixed CRLF/LF line endings create phantom diffs that obscure real changes. Configure your editor and .gitattributes accordingly.
• Keep lines short: Long lines make inline diffs hard to read. A small change in a 200-character line highlights the entire line, burying the actual modification.
• Use meaningful commit messages: Good commit messages help reviewers understand the intent behind each diff without reading every line.

HTML Minification: Optimising for Performance

HTML minification is the process of removing unnecessary characters from HTML source code without changing its functionality. While the savings per file might seem small, they compound across thousands of page loads, especially for high-traffic sites.

What Gets Removed

• Whitespace: Extra spaces, tabs, and line breaks between tags.
• Comments: HTML comments (<!-- ... -->) that are invisible to users but add bytes to the payload.
• Redundant attributes: Default attribute values (e.g., type="text" on inputs) and unnecessary quotes around simple attribute values.
• Optional closing tags: Tags like </li>, </td>, and</p> that HTML5 allows you to omit.
• Empty attributes: Boolean attributes that can be shortened (e.g.,disabled="" → disabled).

<!-- Before: 384 bytes -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <!-- Page title -->
    <title>My Page</title>
  </head>
  <body>
    <div class="container">
      <h1>Hello World</h1>
      <p>Welcome to my website.</p>
    </div>
  </body>
</html>

<!-- After: 137 bytes (64% reduction) -->
<!DOCTYPE html><html lang=en><head><meta charset=UTF-8><title>My Page</title></head><body><div class=container><h1>Hello World</h1><p>Welcome to my website.</div></body></html>

Performance Impact

HTML minification typically reduces file size by 10–30% depending on the original formatting and comment density. The real benefits are:

Integrating Code Quality Tools Into Your Workflow

The best code quality practices are the ones that are automated. Here's how to integrate SQL formatting, diffing, and minification into your daily workflow:

• Pre-commit hooks: Run SQL formatters and HTML minifiers automatically before each commit using tools like Husky (Node.js) or pre-commit (Python).
• CI/CD checks: Add formatting validation to your CI pipeline. Fail the build if SQL or HTML doesn't meet formatting standards.
• Editor integration: Configure your IDE to format SQL on save and highlight diff changes inline. VS Code, JetBrains, and Vim all support SQL formatting plugins.
• Shared configuration: Store formatter settings (.editorconfig, SQL formatter config) in your repository so every team member uses identical settings.

Conclusion

SQL formatting, code diffing, and HTML minification are three pillars of code quality that every developer should master. Properly formatted SQL is easier to read, review, and debug. Clean diffs make code reviews faster and more accurate. And minified HTML delivers a measurably better user experience.

None of these practices require heroic effort — they just require consistency and the right tools. Automate what you can, establish team standards, and make code quality a habit rather than an afterthought.