Team Standards and Style Guides

Individual code style is a luxury that teams can't afford.

When every developer formats code differently, every file becomes a puzzle. "Why is this indented with tabs? Why are there semicolons here but not there? Why are the braces on separate lines?"

None of this helps you understand the code. All of it wastes cognitive energy.

Consistency Over Preference

This is the key insight: it doesn't matter what the standard is, only that there is one.

Tabs vs. spaces? Semicolons vs. no semicolons? Single quotes vs. double quotes?

None of these affect code quality. All of them affect readability—but only when they're inconsistent.

Pick a standard. Everyone follows it. End of discussion.

Enforcing Standards Automatically

The only way standards work is if they're automatic. Humans are bad at noticing formatting issues. Computers are perfect at it.

Editor Configuration

Start with .editorconfig for basic settings:

# .editorconfig
root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

Most editors respect this file automatically.

Formatter Configuration

Add Prettier (or equivalent) for comprehensive formatting:

// .prettierrc
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 100,
  "bracketSpacing": true,
  "arrowParens": "avoid"
}

Linter Configuration

ESLint catches issues Prettier doesn't:

// .eslintrc.json
{
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier"
  ],
  "rules": {
    "no-unused-vars": "error",
    "no-console": "warn",
    "prefer-const": "error"
  }
}

Use eslint-config-prettier to avoid conflicts between ESLint and Prettier.

Pre-commit Hooks

Run checks before code is committed:

// package.json
{
  "scripts": {
    "lint": "eslint . --ext .ts,.tsx",
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  },
  "lint-staged": {
    "*.{ts,tsx,js,jsx}": ["eslint --fix", "prettier --write"],
    "*.{json,md}": ["prettier --write"]
  }
}

With Husky:

npx husky add .husky/pre-commit "npx lint-staged"

Now formatting is fixed automatically before commit.

CI Pipeline

Catch anything that slips through:

# .github/workflows/ci.yml
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
      - run: npm ci
      - run: npm run format:check
      - run: npm run lint

If formatting or linting fails, the build fails.

Popular Style Guides

Don't invent your own style guide. Adopt an existing one.

JavaScript/TypeScript

Airbnb: Most comprehensive, widely used

• Opinionated about everything
• Good defaults for React projects
• Extends ESLint

StandardJS: No configuration needed

• No semicolons
• No config files
• Includes formatter

Google: Enterprise-focused

• More permissive
• Well-documented rationale

Other Languages

Python: PEP 8 + Black formatter
Go: gofmt (the only option)
Rust: rustfmt
Java: Google Java Style

My Recommendation

For JavaScript/TypeScript:

1. Use Prettier for formatting (no debate)
2. Use ESLint with a popular config (Airbnb or TypeScript-ESLint recommended)
3. Customize minimally

The more you customize, the more you maintain.

Handling Disagreements

"But I prefer..."

Stop. Unless there's a concrete productivity reason, personal preference doesn't matter.

The process:

1. Team proposes a change with rationale
2. Team discusses briefly
3. If no consensus, the standard stays
4. If consensus, update the config

Never debate formatting in code review. The tools enforce the rules.

Migration Strategy

When adopting a style guide on an existing codebase:

Option 1: Big Bang

Format everything at once:

npx prettier --write .
git commit -m "Apply consistent formatting"

Pros: Clean history going forward
Cons: Massive diff, git blame is less useful

Option 2: Gradual

Format files as you touch them:

# In pre-commit hook, only format staged files
npx lint-staged

Pros: Minimal disruption
Cons: Inconsistent codebase for a while

Option 3: Combined

Format everything, but as a standalone commit:

# Reformat
npx prettier --write .
git commit -m "chore: apply prettier formatting"

# Configure git blame to ignore that commit
echo "COMMIT_HASH" >> .git-blame-ignore-revs
git config blame.ignoreRevsFile .git-blame-ignore-revs

This is often the best approach.

Documentation

Document your standards:

# Code Style

This project uses:
- **Prettier** for formatting (config in `.prettierrc`)
- **ESLint** with TypeScript rules (config in `.eslintrc.json`)
- **EditorConfig** for basic settings (`.editorconfig`)

## Setup

1. Install the Prettier extension for your editor
2. Enable "Format on Save"
3. Run `npm run lint` before committing

## Why These Choices

We use Airbnb style because it's well-documented and widely understood.
We use single quotes because... actually, it doesn't matter. We just picked one.

Key insight: Style debates are energy sinks. Pick a standard, automate enforcement, and never discuss it again. The tools (Prettier, ESLint, pre-commit hooks) should make compliance automatic. Human code review should focus on logic, not formatting.