# Coding Standards > Baseline coding conventions applicable across projects. Parent: [Software Engineering Patterns](https://llms-explorer.com/tree/software-engineering-patterns/) · 13 facets · 53 facts · page: https://llms-explorer.com/tree/coding-standards/ ## Coding Standards & Best Practices - Baseline coding conventions applicable across projects. — 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. — 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. — 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. — 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. — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#coding-standards-best-practices` ## When to Activate - Starting a new project or module — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate` - Reviewing code for quality and maintainability — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate` - Refactoring existing code to follow conventions — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate` - Enforcing naming, formatting, or structural consistency — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate` - Setting up linting, formatting, or type-checking rules — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate` - Onboarding new contributors to coding conventions — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#when-to-activate` ## Scope Boundaries - Activate this skill for: — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries` - immutability defaults — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries` - readability, KISS, DRY, and YAGNI enforcement — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries` - error-handling expectations and code-smell review — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries` - Do not use this skill as the primary source for: — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries` - React composition, hooks, or rendering patterns — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries` - backend architecture, API design, or database layering — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries` - domain-specific framework guidance when a narrower ECC skill already exists — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#scope-boundaries` ## 1. Readability First - Code is read more than written — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#1-readability-first` - Clear variable and function names — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#1-readability-first` - Self-documenting code preferred over comments — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#1-readability-first` - Consistent formatting — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#1-readability-first` ## 2. KISS (Keep It Simple, Stupid) - Simplest solution that works — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#2-kiss-keep-it-simple-stupid` - Avoid over-engineering — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#2-kiss-keep-it-simple-stupid` - No premature optimization — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#2-kiss-keep-it-simple-stupid` - Easy to understand > clever code — 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 — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#3-dry-dont-repeat-yourself` - Create reusable components — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#3-dry-dont-repeat-yourself` - Share utilities across modules — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#3-dry-dont-repeat-yourself` - Avoid copy-paste programming — 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 — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#4-yagni-you-arent-gonna-need-it` - Avoid speculative generality — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#4-yagni-you-arent-gonna-need-it` - Add complexity only when required — source: `https://llms-explorer.com/sources/mdb-context-hub/coding-standards/#4-yagni-you-arent-gonna-need-it` - Start simple, refactor when needed — 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: — 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. — 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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(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](https://llms-explorer.com/tree/coding-standards/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)*