Coding Standards
Parent: Software Engineering Patterns · Published reference · snapshot 2026-09-08 · skill software-engineering-patterns/references/coding-standards.md
↓ Facts as markdownall context files
Baseline coding conventions applicable across projects.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Coding Standards & Best Practices
- Baseline coding conventions applicable across projects. [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#coding-standards-best-practices]
- This skill is the shared floor, not the detailed framework playbook. [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#coding-standards-best-practices]
- Use frontend-patterns for React, state, forms, rendering, and UI architecture. [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#coding-standards-best-practices]
- Use backend-patterns or api-design for repository/service layers, endpoint design, validation, and server-specific concerns. [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#coding-standards-best-practices]
- Use rules/common/coding-style.md when you need the shortest reusable rule layer instead of a full skill walkthrough. [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#coding-standards-best-practices]
When to Activate
- Starting a new project or module [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate]
- Reviewing code for quality and maintainability [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate]
- Refactoring existing code to follow conventions [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate]
- Enforcing naming, formatting, or structural consistency [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate]
- Setting up linting, formatting, or type-checking rules [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate]
- Onboarding new contributors to coding conventions [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate]
Scope Boundaries
- Activate this skill for: [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries]
- immutability defaults [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries]
- readability, KISS, DRY, and YAGNI enforcement [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries]
- error-handling expectations and code-smell review [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries]
- Do not use this skill as the primary source for: [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries]
- React composition, hooks, or rendering patterns [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries]
- backend architecture, API design, or database layering [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries]
- domain-specific framework guidance when a narrower ECC skill already exists [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries]
1. Readability First
- Code is read more than written [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#1-readability-first]
- Clear variable and function names [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#1-readability-first]
- Self-documenting code preferred over comments [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#1-readability-first]
- Consistent formatting [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#1-readability-first]
2. KISS (Keep It Simple, Stupid)
- Simplest solution that works [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#2-kiss-keep-it-simple-stupid]
- Avoid over-engineering [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#2-kiss-keep-it-simple-stupid]
- No premature optimization [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#2-kiss-keep-it-simple-stupid]
- Easy to understand > clever code [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#2-kiss-keep-it-simple-stupid]
3. DRY (Don't Repeat Yourself)
- Extract common logic into functions [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#3-dry-dont-repeat-yourself]
- Create reusable components [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#3-dry-dont-repeat-yourself]
- Share utilities across modules [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#3-dry-dont-repeat-yourself]
- Avoid copy-paste programming [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#3-dry-dont-repeat-yourself]
4. YAGNI (You Aren't Gonna Need It)
- Don't build features before they're needed [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#4-yagni-you-arent-gonna-need-it]
- Avoid speculative generality [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#4-yagni-you-arent-gonna-need-it]
- Add complexity only when required [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#4-yagni-you-arent-gonna-need-it]
- Start simple, refactor when needed [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#4-yagni-you-arent-gonna-need-it]
Code Smell Detection
- Watch for these anti-patterns: [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#code-smell-detection]
3. Magic Numbers
- Remember: Code quality is not negotiable. Clear, maintainable code enables rapid development and confident refactoring. [archived source: https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#3-magic-numbers]
Where this helps
- Starting a new project or module and wanting a shared baseline — readability, KISS, DRY, YAGNI — before framework-specific conventions get layered on top. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Reviewing code for quality and maintainability and needing a shared vocabulary, a named code smell or a named principle, instead of purely subjective feedback. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Refactoring existing code to follow conventions and needing to know where this baseline skill's scope ends and a framework-specific playbook, such as one for React, begins. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Deciding whether a piece of duplicated logic should be extracted under DRY or left alone because premature abstraction would cost more than the duplication does. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
How to apply this
- Default to the simplest solution that works, KISS, and treat added complexity as something that must be justified by an actual current requirement, not a speculative future one, YAGNI. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Prefer self-documenting code with clear variable and function names over comments that explain what confusing code does; fix the naming first, comment only what the code can't say for itself. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Extract genuinely repeated logic into shared functions or components, DRY, but only once the duplication is real and recurring, not on the first sighting of similar-looking code. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Watch for named code smells, such as magic numbers, during review and replace them with named constants so the meaning of a literal value is documented at its point of use. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Antipatterns
- Over-engineering a solution for requirements that don't exist yet, violating YAGNI in the name of future-proofing. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Extracting an abstraction after seeing the same logic only once or twice, before the duplication is actually established, which tends to produce the wrong abstraction. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Optimizing code before establishing that the code path is actually a performance bottleneck, premature optimization, trading readability for speed nobody asked for. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Relying on comments to explain what a poorly named variable or function does, instead of renaming it so the code documents itself. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Known issues
- This skill is explicitly the shared floor, not the detailed framework playbook; it deliberately doesn't cover React, state management, or other framework-specific concerns, so applying it alone leaves real gaps for framework-heavy code. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- KISS, DRY, and YAGNI are principles that can conflict in practice, since a simple solution can also be a duplicated one, and the baseline doesn't resolve every such tension. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Self-documenting code is a default, not an absolute; some logic, such as a non-obvious business rule or a workaround for an external bug, genuinely needs a comment no naming scheme can replace. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Code smell detection, like spotting magic numbers, catches surface-level issues but doesn't substitute for a deeper architectural review; a codebase can pass every smell check and still have a bad overall design. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Children
- Naming and Readability Conventions (frontier)
- TypeScript and JavaScript Standards (frontier)
- React Best Practices (frontier)
- File Organization (frontier)
- Testing Standards (frontier)
Frontier under this node: File Organization, Naming and Readability Conventions, React Best Practices, Testing Standards, TypeScript and JavaScript Standards