Contributing to an Existing CodebaseLesson 5.2

How to match the coding style of a codebase you're contributing to

reading .eslintrc and .prettierrc, inferring style from existing code, naming convention consistency, error handling patterns, async patterns, test structure matching

Your Code Should Look Like It Belongs

When you add code to a codebase, it should be indistinguishable from the existing code. Inconsistent style creates cognitive friction for every future reader — including you.

Read the Config Files First

// .eslintrc.json tells you enforced rules
{
  "rules": {
    "prefer-const": "error",       // use const, not let, by default
    "no-var": "error",             // never use var
    "arrow-body-style": "error",   // use implicit returns in arrows
    "eqeqeq": "error"             // always use === not ==
  }
}

// .prettierrc tells you formatting
{
  "singleQuote": true,     // 'string' not "string"
  "semi": false,           // no semicolons
  "tabWidth": 2,
  "printWidth": 100
}

What Config Files Don't Cover

ESLint doesn't enforce naming conventions, error handling patterns, or test structure. For these, read 3-5 existing functions in the same module and match exactly:

// If the codebase throws custom errors:
throw new ValidationError('Email is required', { field: 'email' });
// Your code should too — not: throw new Error('Email is required')

// If the codebase uses async/await everywhere:
const user = await userService.find(id);
// Don't introduce Promises with .then() chains

// If tests use a specific describe() structure:
// describe('ServiceName > methodName') — match it exactly