Script Valley
Open Source Contribution: A Practical Guide
Code Quality and Testing StandardsLesson 4.1

How to read and match a project's existing code style

EditorConfig, ESLint, Prettier, linting configuration files, style guide documents, matching idioms, code imitation as strategy, Python Black and flake8

Match the Room

Every project has a style. Your job is to match it, not introduce yours. A PR that looks stylistically foreign signals that the contributor did not read the existing code.

The Configuration Files

.editorconfig -- Defines tab vs spaces, line endings, indent size. Install the EditorConfig plugin for your editor and it applies automatically.

.eslintrc or eslint.config.js -- JavaScript linting rules. Run npm run lint or npx eslint src/.

.prettierrc -- Opinionated JS/TS formatting. Run npx prettier --write . before committing.

pyproject.toml or setup.cfg -- Python config for Black, flake8, isort.

Reading the Code

Before writing anything, read 10 existing functions in the module you are modifying. Note: naming conventions, error handling patterns, how async is handled, how imports are organized. Then write code that looks like it was written by the same person.

# Python -- check formatting and linting before pushing
black .
flake8 .
isort .

# JavaScript
npx eslint . --fix
npx prettier --write .

If you disagree with a style rule, do not fix it in your PR. That is a separate conversation -- open an issue. Mixing style changes with bug fixes makes diffs unreadable.

Up next

How to write unit tests for an open source contribution

Sign in to track progress