How to create a team clean code standard document

Unwritten team standards produce inconsistent code and endless debate in code reviews. Written standards end debates before they start. Every team working on a shared codebase needs a clean code standards document.

The document lives in CONTRIBUTING.md in the repository root — always discoverable, always version-controlled alongside the code it governs.

What to include:

## Naming Conventions
- Variables: camelCase, intention-revealing, no abbreviations
- Constants: SCREAMING_SNAKE_CASE
- Booleans: must use is/has/can prefix
- Functions: must start with a verb

## Function Rules  
- Maximum 20 lines
- Maximum 3 parameters (use object for more)
- No flag arguments
- Side effects must be named explicitly

Add a PR checklist that reviewers verify before approval:

## PR Checklist
- [ ] All new functions have intention-revealing names
- [ ] No function exceeds 20 lines
- [ ] No magic numbers or strings
- [ ] Public functions have JSDoc
- [ ] Lint passes with zero warnings

The document must be short enough to read in 10 minutes. If it's longer than two pages, it won't be read. Cover only the decisions where inconsistency has caused real problems on your team — not every theoretical principle.

Review and update it quarterly. As your team's skills improve and your tooling changes, the standards should evolve. Outdated standards become obstacles rather than guides.