Code Quality Tools: SonarQube, ESLint, Prettier, Checkstyle, and CodeClimate

Code quality tools automate the detection of bugs, code smells, style violations, and security vulnerabilities — providing consistent, objective feedback on code quality without relying on manual review for routine checks.

What You’ll Learn

• How SonarQube provides comprehensive code quality analysis
• Using ESLint and Prettier together for JavaScript/TypeScript projects
• Checkstyle and PMD for Java code quality
• CodeClimate for Git-integrated quality metrics
• Building an automated code quality pipeline in CI

Why Code Quality Tools Matter

Manual code review is invaluable for design and logic, but it’s inefficient for catching style violations, simple bugs, and security issues that automated tools can detect instantly. A study by SmartBear found that developers miss 50% of bugs in code review — tools catch many of those. Automated quality tools also enforce consistency across the team, eliminating style debates and ensuring every commit meets the same standards.

Durga Antivirus Pro uses SonarQube to enforce quality gates on every scanner module — a complexity score above 15 or coverage below 80% blocks the build.

Learning Path

    flowchart LR
  A[Static Analysis] --> B[Quality Metrics]
  B --> C[Code Quality Tools<br/>You are here]
  C --> D[CI/CD Integration]
  D --> E[Production Monitoring]
  style C fill:#f90,color:#fff
  

SonarQube

SonarQube is the most comprehensive code quality platform, supporting 30+ languages with automatic analysis of bugs, vulnerabilities, code smells, and technical debt.

Setup

# Docker-based setup
docker run -d --name sonarqube \
  -p 9000:9000 \
  sonarqube:community

# Access at http://localhost:9000 (admin/admin)

Running Analysis

# With sonar-scanner CLI
sonar-scanner \
  -Dsonar.projectKey=myapp \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.token=sqp_xxxxxxxxxx

Quality Gates

SonarQube quality gates define minimum quality standards:

<!-- sonar-project.properties -->
sonar.projectKey=myapp
sonar.sources=src
sonar.tests=src
sonar.language=py
sonar.python.coverage.reportPaths=coverage.xml
sonar.qualitygate=true

<!-- Quality gate conditions -->
<!-- Coverage: >= 80% -->
<!-- Duplicated lines: < 3% -->
<!-- Maintainability rating: A or B -->
<!-- Security rating: A -->

Interpretation

SonarQube rates code on a scale of A (best) to E (worst) for three dimensions:

ESLint

ESLint is the standard linter for JavaScript and TypeScript, finding problematic patterns and enforcing coding conventions.

Configuration

// eslint.config.js (flat config format)
export default [
  {
    files: ['src/**/*.{js,jsx,ts,tsx}'],
    rules: {
      // Possible problems
      'no-unused-vars': 'error',
      'no-undef': 'error',
      'no-duplicate-imports': 'error',

      // Suggestions
      'prefer-const': 'error',
      'no-var': 'error',
      'eqeqeq': ['error', 'always'],

      // Best practices
      'no-console': 'warn',
      'no-alert': 'warn',
      'max-depth': ['error', 3],
      'max-lines-per-function': ['warn', 50],
    },
  },
];

Running

# Check all files
npx eslint src/

# Auto-fix what can be fixed
npx eslint src/ --fix

# Output
/Users/dev/src/app.js
  5:7  error    'result' is assigned but never used  no-unused-vars
  12:2  warning  Unexpected console statement          no-console
  20:1  error    Expected indentation of 4 spaces      indent

✖ 3 problems (2 errors, 1 warning)
  1 error and 0 warnings potentially fixable with the `--fix` option.

Prettier

Prettier is an opinionated code formatter that eliminates style debates by automatically formatting code.

Configuration

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 100,
  "arrowParens": "always"
}

ESLint + Prettier Integration

Use ESLint for logic rules and Prettier for formatting:

// eslint.config.js — disable formatting rules, let Prettier handle them
export default [
  {
    files: ['src/**/*.{js,jsx,ts,tsx}'],
    rules: {
      'indent': 'off',      // Prettier handles indentation
      'quotes': 'off',       // Prettier handles quotes
      'semi': 'off',         // Prettier handles semicolons
      'comma-dangle': 'off', // Prettier handles trailing commas
    },
  },
];

# Run both
npx prettier --check src/ && npx eslint src/

# Or combine in a script
# package.json
{
  "scripts": {
    "format": "prettier --write src/",
    "lint": "eslint src/",
    "quality": "npm run format && npm run lint"
  }
}

Checkstyle (Java)

Checkstyle enforces Java coding standards.

Configuration

<!-- checkstyle.xml -->
<!DOCTYPE module PUBLIC
  "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN"
  "https://checkstyle.org/dtds/configuration_1_3.dtd">
<module name="Checker">
  <module name="TreeWalker">
    <!-- Naming conventions -->
    <module name="ConstantName"/>
    <module name="LocalFinalVariableName"/>
    <module name="MemberName">
      <property name="format" value="^[a-z][a-zA-Z0-9]*$"/>
    </module>

    <!-- Code structure -->
    <module name="MethodLength">
      <property name="max" value="30"/>
    </module>
    <module name="CyclomaticComplexity">
      <property name="max" value="10"/>
    </module>

    <!-- Imports -->
    <module name="AvoidStarImport"/>
    <module name="UnusedImports"/>
  </module>
</module>

Running

java -jar checkstyle.jar -c checkstyle.xml src/
# Output:
# [WARN] src/main/java/UserService.java:45: Method length is 45 lines (max allowed 30)
# [ERROR] src/main/java/Utils.java:12: Name 'MAX_SIZE' must match pattern '^[a-z][a-zA-Z0-9]*$'

CodeClimate

CodeClimate provides Git-integrated quality analysis with automated PR comments.

Configuration

# .codeclimate.yml
version: "2"
plugins:
  eslint:
    enabled: true
    channel: "eslint-8"
  duplication:
    enabled: true
    config:
      languages:
        javascript:
          mass_threshold: 50
        python:
          mass_threshold: 40
  fixme:
    enabled: true
    config:
      strings:
        - TODO
        - FIXME
        - HACK
ratings:
  paths:
    - "**.js"
    - "**.py"
exclude_patterns:
  - "**/*.test.js"
  - "**/vendor/"

CI Integration

# .github/workflows/quality.yml
name: Code Quality
on: [push, pull_request]

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

      # JavaScript quality
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npx prettier --check src/
      - run: npx eslint src/

      # SonarQube scan
      - name: SonarQube Scan
        uses: SonarSource/sonarcloud-github-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

Common Code Quality Tool Mistakes

1. Too Many Rules

Hundreds of rules create noise. Developers learn to ignore the linter.

Fix: Start with a minimal, opinionated config (recommended rules). Add rules only when a pattern causes real problems.

2. No Auto-Formatting

Enforcing formatting manually wastes code review time on style issues.

Fix: Use Prettier or a formatter with --fix on save. Remove formatting rules from the linter.

3. Running Tools Without Fixing Issues

Running SonarQube but not acting on the results is worse than not running it — it creates the illusion of quality.

Fix: Set quality gates that block builds. Track the issue count over time.

4. Ignoring False Positives

A rule that produces 50% false positives will be ignored entirely.

Fix: Configure or disable noisy rules. Document known false positives with inline suppression.

5. Different Configs on Different Machines

“Works on my machine” applies to linters too. Different developers get different results.

Fix: Commit config files and run linters in CI with the same config.

6. No Pre-commit Hooks

Developers don’t remember to run linters before committing.

Fix: Use pre-commit hooks (Husky, pre-commit) to auto-format and lint before every commit.

7. Treating Tools as a Silver Bullet

Tools catch patterns, not design problems. They complement code review, not replace it.

Fix: Use tools for what they’re good at (style, simple bugs, security patterns). Use review for design, architecture, and logic.

Practice Questions

1. What is the difference between ESLint and Prettier?

ESLint finds logical errors and enforces coding conventions (rule-based). Prettier formats code automatically (style-based). They complement each other.

2. What are SonarQube quality gates?

Minimum quality thresholds (coverage, complexity, duplications, security rating) that code must meet before it can be merged or deployed.

3. Why should formatting rules be removed from ESLint when using Prettier?

Prettier handles formatting more comprehensively and consistently. ESLint formatting rules conflict with Prettier and create redundant work.

4. How does CodeClimate differ from SonarQube?

CodeClimate is cloud-based with Git integration for automated PR comments. SonarQube can be self-hosted, supports more languages, and offers deeper analysis.

5. What is the recommended approach for adopting code quality tools in a legacy codebase?

Start with the strictest rules on new code only, gradually enable rules on legacy code as it’s modified, and fix the most critical issues first.

Challenge: Set up SonarQube with Docker, configure quality gates for a sample project, and integrate it into a GitHub Actions pipeline. The pipeline should block PRs that fail the quality gate.

FAQ

What’s Next

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro. Updated 2026-06-20.