One source of truth for how your team writes code
Style debates in code review are a tax on every pull request. A coding standards guide settles them once: it defines how the team names things, structures files, writes comments, handles errors, and reviews changes. This builder produces a clean, repo-ready Markdown guide so new and existing engineers all follow the same playbook.
How it works
The builder organizes your inputs into the sections every good standards guide needs. Naming conventions define casing and patterns for variables, functions, classes, and files. File and folder structure describes where code lives and how modules are organized. Comment standards set expectations for when and how to document code. Error handling captures the team’s pattern for raising, catching, and logging errors. The code review checklist lists what every reviewer verifies before approving.
Each list-style field renders as bullets and the language you specify scopes the whole document, producing plain Markdown that commits straight into a CONTRIBUTING.md or style guide.
What a good standards guide covers
Naming conventions
Every section should state the rule, the casing pattern, and a short example in the language you work in. For example:
| Entity | Convention | Example |
|---|---|---|
| Variables | camelCase | userProfile, isActive |
| Constants | UPPER_SNAKE | MAX_RETRIES, API_BASE_URL |
| Classes | PascalCase | UserService, OrderRepository |
| Files | kebab-case | user-service.ts, order-repository.ts |
| Booleans | is/has/can prefix | isValid, hasAccess, canEdit |
File structure
Describe where things live. For example: “All services go in src/services/, each in its own directory. A service directory contains index.ts (the public surface), service.ts (business logic), repository.ts (data access), and types.ts (local types).” Explicit structure means new engineers know where to put and find code without asking.
Error handling
Pick one pattern and enforce it. A common rule: “All errors should be typed classes that extend a base AppError. Services throw errors; controllers catch them and map to HTTP responses. Use structured logging (logger.error({ err, context })) rather than console.error.”
Code review checklist
The checklist should be short enough to actually use on every PR. Eight items is a healthy maximum:
- Tests added or updated for the change
- No secrets or credentials committed
- Naming follows the guide
- Error paths handled
- No N+1 database queries introduced
- Public APIs have types or documentation
- Breaking changes flagged to dependents
- No commented-out code
Tips
- Pair every naming rule with a concrete example — abstract rules are ignored; examples stick.
- Keep the error-handling section opinionated: ambiguity means each engineer invents their own pattern.
- Commit the guide to the repository so changes go through the same review process as code.
- Link the guide from the README so it is the first thing a new engineer reads.