A style guide turns a team’s shared code-style decisions into agreed expectations, preventing personal preferences from becoming review obstacles or sources of resentment. section 4.2.3 section 5.2.1
Rules can be applied consistently by formatters instead of debated manually. This keeps codebases consistent, teaches newer developers, and leaves reviewers more attention for substantive issues. section 5.2.1 section 5.3.1
Build the practice around shared decisions and automated enforcement:
- Develop and discuss standards as a team before adding them to the Team Working Agreement. section 4.2.3
- Run formatting checks locally and as pull-request gates so basic style failures are surfaced before review. section 5.3.1
- Keep trivial style differences nonblocking; define separately when approval may be withheld or a pull request rejected. section 4.2.3
JavaScript brace style
A team can configure ESLint to enforce Stroustrup brace style with brace-style: ["error", "stroustrup"]. Correct and incorrect JavaScript examples make the rule visible. section 5.2.1
Listing 5.1 ESLint Rule enforcing Stroustrup brace style
// eslint rule that enforces Stroustrup brace style. brace-style: ["error", "stroustrup"]
View the ESLint rule configuration that encodes the team’s brace-style decision. section 5.2.1
