Code Quality & Review — เขียน Code ดีๆ ที่ทีมอยากอ่าน 🔍Code Quality & Review — Writing Code Your Team Wants to Read 🔍

In the previous post we looked at GitHub Actions and how it automates CI/CD — but however good the pipeline is, it cannot save bad code inside it!

Today we look at Code Quality — how to make code readable, maintainable, low on bugs, and pleasant for a team to work on together 🔍🐕

🤔 Why Does Code Quality Matter?

Picture yourself coming back to fix code you wrote six months ago — if it is unreadable, has no tests and no documentation, you will spend more time understanding it than actually fixing it! Code quality is not a matter of "prettiness"; it is a real cost — low-quality code means more bugs, slower fixes, deploys you dread, and new developers left confused.

💡 "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." — Martin Fowler

🧹 Linting & Formatting — Making Tidy Code Mandatory

Linting means using tools that inspect code automatically to find bugs, bad practices and style issues, while Formatting means laying code out identically across the whole team (indentation, quotes, semicolons) — no more arguing about tabs versus spaces! Once it is set up, everyone on the team writes in the same style automatically.

ESLint (JavaScript/TypeScript)

ESLint is the most popular linter for JavaScript and TypeScript — its rules can be customized to whatever the team needs, from banning the any type to enforcing naming conventions. The example below shows a config worth starting from:

# install
npm install --save-dev eslint @eslint/js typescript-eslint

# eslint.config.js
import js from '@eslint/js';
import tseslint from 'typescript-eslint';

export default [
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    rules: {
      'no-console': 'warn',             // console.log = warning
      'no-unused-vars': 'error',         // unused variable = error
      'no-var': 'error',                 // never use var
      'prefer-const': 'error',           // use const when never reassigned
      'eqeqeq': 'error',               // no ==, always ===
      '@typescript-eslint/no-explicit-any': 'warn',
    }
  }
];

# run
npx eslint .                            # check
npx eslint . --fix                      # check + fix automatically

Prettier (Auto-format)

Prettier works alongside ESLint — ESLint looks after "right or wrong", Prettier looks after "tidy or untidy". Configure it once and Prettier formats your code on every save — no more hand-arranging whitespace:

# install
npm install --save-dev prettier

# .prettierrc
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 80
}

# run
npx prettier --write .                  # format every file
npx prettier --check .                  # check (in CI)

Python — Ruff (The Fastest!)

Ruff is a new Python linter and formatter written in Rust — 10 to 100 times faster than flake8 + isort + black combined! Instead of configuring three separate tools, Ruff does all of it in one:

# install
pip install ruff

# pyproject.toml
[tool.ruff]
line-length = 88
select = ["E", "F", "W", "I", "N", "UP"]
ignore = ["E501"]

[tool.ruff.format]
quote-style = "double"

# run
ruff check .                            # lint
ruff check . --fix                      # lint + fix
ruff format .                           # format (replaces black)

Pre-commit Hooks — Enforced Before the Commit

The trouble with linting and formatting is that a developer can forget to run them! Pre-commit hooks solve that by running lint and format automatically before every commit — if the code does not pass, the commit fails. No more relying on "discipline", because the system enforces it:

# install
npm install --save-dev husky lint-staged
npx husky init

# .husky/pre-commit
npx lint-staged

# package.json
{
  "lint-staged": {
    "*.{js,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,md,yml}": [
      "prettier --write"
    ]
  }
}

# now every git commit → auto lint + format!
# ❌ code that fails lint = no commit

🔍 Code Review — The Art of Reviewing Code

Automated tools catch bugs, but they cannot tell you "is this approach correct?" or "is there a better design here?". That is the job of Code Review — the process where another developer reads your code and gives feedback. It is not only about finding bugs; it spreads knowledge, sets standards, and catches the problems no tool can see.

Code Review Flow

A good code review process needs a clear flow — from the developer opening a PR all the way to the merge into the main branch. The important part is reviewing within 24 hours, so the team's workflow is never blocked:

What Should a Reviewer Look At?

A good reviewer does not just read syntax — they look at correctness, design, readability, performance, security and test coverage. The guiding question is "Could a new team member understand this code?" If the answer is no, the code needs work:

What a Good Review Comment Looks Like

A good review comment explains "why" instead of simply saying "change this" — so the developer learns and does not repeat the mistake. Suggest the fix, show sample code, and keep the tone constructive rather than critical:

🐕 Review Culture: Review the code, not the person — "this code could…" rather than "you wrote this badly…" | Use "Nit:" for small nitpicks | Praise good code when you see it 👍

🧠 SOLID Principles — The Rules of Good Code

SOLID is a set of five software design principles that keep code flexible, maintainable and extensible, formulated by Robert C. Martin (Uncle Bob). The names sound intimidating, but the core is simple — separate concerns clearly, give each part one job, and make change easy. Here they are one by one:

Example: Single Responsibility

The Single Responsibility Principle (SRP) says that each class or function should have exactly one reason to change. If a function validates, saves and sends email all at once, touching the email logic can break the save logic! The example below compares code that violates SRP with code that follows it:

🚨 Code Smells — When Code Starts to Stink

Code smells are "signals" that code may be in trouble — not bugs in themselves, but patterns that point to a poor design. Left alone they turn into technical debt that gets harder to pay off. They are like a smell: nothing hurts you immediately, but something in there is rotting!

Example: Deep Nesting → Early Return

One of the most common code smells is deep nesting — if inside if inside if until nobody can read it. The fix is the early return pattern: check the error cases first and return immediately, which leaves the "happy path" at the outermost level and easy to read:

📊 Static Analysis — Let the Machine Inspect It

Beyond linters there are static analysis tools that examine code far more deeply — finding code smells automatically, measuring complexity, detecting security vulnerabilities, and tracking technical debt over time. Think of them as a "third eye" helping the reviewer.

SonarQube / SonarCloud

SonarQube (self-hosted) or SonarCloud (managed) is the most complete code-analysis platform there is — it plugs into GitHub Actions, scans every PR, and reports the results on a dashboard full of metrics:

# GitHub Actions + SonarCloud
name: Quality Gate

on: [push, pull_request]

jobs:
  sonarcloud:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0                 # full history for blame

      - name: SonarCloud Scan
        uses: SonarSource/sonarcloud-github-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        with:
          args: >
            -Dsonar.projectKey=myorg_myapp
            -Dsonar.organization=myorg
            -Dsonar.sources=src
            -Dsonar.tests=tests
            -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info

What Does SonarQube Measure?

SonarQube measures code quality across five main dimensions — bugs, vulnerabilities, code smells, coverage and duplications. Each carries a grade from A to E, which makes the overall picture quick to read:

Quality Gate — Pass or Fail

A quality gate is the checkpoint that defines the minimum a change must meet before it can be merged — coverage above 80%, no critical bugs, duplications under 3%. Fail it and the PR fails automatically:

# Quality Gate Conditions (SonarQube default)
# ──────────────────────────────────────────
# ✅ PASS if:
#   - New code coverage > 80%
#   - New code duplications < 3%
#   - New bugs = 0 (A rating)
#   - New vulnerabilities = 0 (A rating)
#   - New code smells ≤ A rating
#   - New security hotspots reviewed 100%
#
# ❌ FAIL → the PR cannot be merged!
# → quality enforced automatically, no need to rely on the reviewer

🛠️ The Full Toolkit

Here is every tool used to keep code quality up, grouped by category so it is easy to choose from. You do not need all of them — start with a linter and a formatter, then add more as the team is ready:

📋 CI/CD Quality Pipeline

Time to bring every tool together in GitHub Actions! The pipeline below shows the quality checks worth running on every PR, ordered fastest to slowest — format check (seconds) → lint (seconds) → type check (a minute) → tests + coverage (minutes) → SonarCloud (minutes):

# .github/workflows/quality.yml
name: Code Quality

on: [push, pull_request]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - run: npm ci

      # Step 1: Format check
      - name: Check formatting
        run: npx prettier --check .

      # Step 2: Lint
      - name: Lint
        run: npx eslint .

      # Step 3: Type check
      - name: Type check
        run: npx tsc --noEmit

      # Step 4: Tests + coverage
      - name: Tests
        run: npm test -- --coverage

      # Step 5: Coverage threshold
      - name: Check coverage threshold
        run: |
          COVERAGE=$(jq '.total.lines.pct' coverage/coverage-summary.json)
          echo "Coverage: $COVERAGE%"
          if (( $(echo "$COVERAGE < 80" | bc -l) )); then
            echo "❌ Coverage below 80%!"
            exit 1
          fi

      # Step 6: SonarCloud
      - uses: SonarSource/sonarcloud-github-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

The pipeline above orders its checks from fast to slow, and from basic to sophisticated. Starting with the formatting check gives the fastest possible feedback when code does not meet the standard, followed by linting, which catches syntax and the basic rules.

Type checking then catches type-safety mistakes, which matters enormously in TypeScript. Running the tests together with coverage confirms that the functionality still works and that test coverage is adequate. The final step is SonarCloud, which performs the deep analysis and gathers all of the metrics together.

📝 Clean Code Checklist

Having gone through the tools and the processes, the thing that matters is putting these principles and practices to work in the code you write every day. The Clean Code Checklist below is a guideline developers can use both when writing and when reviewing code.

The checklist gathers the principles that make code good, each one covering a different angle — from naming, to function design, to sound development process. Following it raises code quality in a systematic way:

1. Naming: variable and function names carry meaning — getUserById, not getData
2. Functions: short, doing one thing, no more than 20 lines
3. DRY: Don't Repeat Yourself — extract shared logic
4. KISS: Keep It Simple, Stupid — do not over-engineer
5. Comments: explain "why", not "what" — the code says what, the comment says why
6. Error Handling: handle errors explicitly, never catch and swallow silently
7. No Magic: use constants instead of magic numbers and strings
8. Consistent: one style across the whole codebase (enforced by a linter)
9. Tests: every important function has a test
10. Small PRs: small PRs are easy to review — no more than 400 lines changed

The checklist covers every important aspect of quality code, from technical matters such as naming conventions and error handling through to process matters such as code review and keeping PRs small. Following all of it may look like a lot, but once it becomes habit it happens automatically.

💡 The Boy Scout Rule: "Leave the code better than you found it" — when you meet a code smell, fix it a little at a time; there is no need to wait for a big refactor.

The Boy Scout Rule is simple but powerful. Fixing small code smells a little at a time stops technical debt from accumulating into a serious problem. It is a more sustainable approach than waiting for the problem to grow and then refactoring everything at once, and it gives the team a stronger sense of ownership over the codebase.

Summary

Code quality is something you work at continuously and systematically, not something you do once and finish. The tools covered in this post make building and preserving that quality automatic, and far more effective.

The most important thing is building a team culture that values code quality. Tools are only aids; the heart of it is a mindset and a team culture that wants to write good code, help one another, and learn from one another. That is where sustainable software development begins:

• Linting + Formatting = ESLint + Prettier (JS) / Ruff (Python), style enforced by machine
• Pre-commit hooks = Husky + lint-staged → no commit if the code does not pass
• Code Review = look at correctness, readability, design, security, tests
• SOLID Principles = five OOP design principles that keep code easy to maintain
• Code Smells = magic numbers, deep nesting, god class → fix with early return, extract function
• Static Analysis = SonarQube/SonarCloud measuring bugs, vulnerabilities, coverage, debt
• Quality Gates = a PR cannot merge unless it passes the quality threshold
• Clean Code = good naming, small functions, DRY, KISS, the Boy Scout Rule 🔍🐕

None of this has to arrive all at once. Start with the basic tools — a linter and a formatter — then add static analysis, a code review process and quality gates as the team is ready. What matters is consistency and continuous improvement, because code quality is not a destination but a journey with no end 🔍🐕