Linting

Linting is the process of analysing code to find potential errors, bugs, stylistic issues, and suspicious constructs. A linter is an automated tool that enforces code quality and consistency across a codebase. Ironically, linting is often the very first thing an inexperienced coder turns off - seeing it as annoying or unnecessary - while experienced developers keep it enabled by default and simply address problems as they arise, knowing that linters ultimately save time and headaches.

Why Lint?

• Catch bugs early: Find issues before they reach production
• Onboard faster: New developers learn conventions automatically
• Enforce consistency: Same style across the entire codebase
• Improve code review: Focus on logic, not formatting
• Prevent debates: Style discussions become configuration decisions

Popular Linters by Language

Language	Linter	Style Guide
JavaScript/TypeScript	ESLint	Airbnb, Standard
Python	Ruff, Flake8, Pylint	PEP 8, Black
PHP	PHP_CodeSniffer, PHPStan	PSR-12
CSS	Stylelint	Property order, naming
Go	golint, staticcheck	Built-in
Rust	Clippy	Built-in

ESLint Configuration

// .eslintrc.js
module.exports = {
  extends: [
    'airbnb',
    'airbnb-typescript',
    'plugin:@typescript-eslint/recommended',
  ],
  parserOptions: {
    project: './tsconfig.json',
  },
  rules: {
    'no-console': 'warn',
    'import/prefer-default-export': 'off',
    '@typescript-eslint/no-unused-vars': 'error',
  },
};

Formatters vs Linters

Tool	Purpose	Examples
Formatter	Code style (whitespace, quotes)	Prettier, Black
Linter	Code quality (bugs, patterns)	ESLint, Flake8

Best practice: Use both. Let Prettier handle formatting, ESLint handle quality.

// .eslintrc.json
{
  "extends": ["eslint:recommended", "prettier"]
}

Integrating Linting

IDE Integration

Most editors show lint errors inline (VS Code, WebStorm, etc.)

Pre-commit Hooks

# Using Husky + lint-staged
npx husky install
npx husky add .husky/pre-commit "npx lint-staged"

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

CI/CD Pipeline

# GitHub Actions
- name: Lint
  run: npm run lint

What We Like

• Team alignment: Shared configuration = shared standards
• Automated quality: Consistent code without manual review
• Auto-fix: Many issues resolved automatically
• IDE feedback: Immediate visibility of issues

What We Don't Like

• Configuration overhead: Initial setup can be complex
• False positives: Sometimes (rarely) rules conflict with valid patterns
• Performance: Large codebases can be slow to lint

Best Practices

1. Start with established configs: Airbnb, Standard, or framework defaults
2. Enable auto-fix: Let tools do the work
3. Lint in CI: Fail builds on lint errors
4. Use pre-commit hooks: Catch issues before commit
5. Document exceptions: When disabling rules, explain why