Coding Standards

Coding Standards

> D9 Canonical Reference. This is the single source of truth for cross-language coding standards. > Language-specific reviewers (@typescript-reviewer, @python-reviewer, etc.) embed these rules. > Agents cite this skill as "See also: /coding-standards."

Naming Conventions

Variables & Functions

| Language | Variables | Functions | Constants | |----------|-----------|-----------|-----------| | TypeScript / JavaScript | camelCase | camelCase | SCREAMING_SNAKE_CASE | | Python | snake_case | snake_case | SCREAMING_SNAKE_CASE | | Go | camelCase | camelCase | CamelCase (exported) | | Rust | snake_case | snake_case | SCREAMING_SNAKE_CASE | | Java | camelCase | camelCase | SCREAMING_SNAKE_CASE | | C# | camelCase | PascalCase | PascalCase | | Swift | camelCase | camelCase | camelCase |

Classes / Types / Interfaces

PascalCase — all languages, no exceptions.

Booleans

Prefix with is, has, can, should: isLoading, hasError, canEdit, shouldRefresh.

Collections

Plural nouns: users, errors, items — not userList, errorArray.

Avoid

• Single-letter variables outside loop counters (i, j, k are OK in loops)
• Abbreviations that save under 3 characters: usr → user, mgr → manager
• Redundant type names: UserInterface, UserClass, UserObject → just User

---

Function Design

• Max length: 50 lines (firm guideline; > 80 lines is always a split target)
• Single responsibility: one function, one job — if "and" appears in the description, split it
• Max parameters: 3; beyond that, use an options/config object
• Cyclomatic complexity: ≤ 10; > 15 is a mandatory refactor target
• Nesting depth: ≤ 3 levels; use early returns to flatten

Early Return Pattern (preferred)

// BEFORE — deep nesting
function handle(input) {
  if (input) {
    if (input.valid) {
      return process(input);
    }
  }
  return null;
}

// AFTER — early returns
function handle(input) {
  if (!input || !input.valid) return null;
  return process(input);
}

---

Error Handling

• Never swallow errors silently: catch (e) {} is always wrong
• Error messages must contain context: "Failed to fetch user id=42" not "Error"
• Propagate or handle: either handle the error at the right level OR re-throw it — never both and never neither
• Typed errors (TypeScript): class NotFoundError extends Error { constructor(id: string) ... } not generic new Error
• Python exceptions: catch specific exception types; bare except: is forbidden
• Go errors: always check returned errors; use errors.Is()/errors.As() for comparison
• Rust results: use ? for propagation; no .unwrap() in library code

---

Code Structure

Immutability-First

• const over let (JS/TS); val over var (Swift/Kotlin); final where appropriate
• Mark fields readonly when not reassigned after construction
• Prefer immutable data structures for function arguments

No Magic Numbers

// BAD
if (retries > 3) { ... }
setTimeout(fn, 5000);

// GOOD
const MAX_RETRIES = 3;
const POLL_INTERVAL_MS = 5000;
if (retries > MAX_RETRIES) { ... }
setTimeout(fn, POLL_INTERVAL_MS);

No Commented-Out Code

If it is dead → delete it (git history preserves it). If it is needed soon → it should be in a branch. If it explains a non-obvious decision → keep it as a comment, not commented-out code.

---

Anti-Patterns Reference

| Pattern | Severity | Reason | |---------|----------|--------| | Mutable global state | HIGH | Unpredictable side effects; hides dependencies | | Promise not awaited | HIGH | Unhandled async errors silently swallowed | | any in TypeScript | MEDIUM | Bypasses type safety across call boundaries | | console.log in production code | LOW | Log noise; potential data leak in sensitive contexts | | TODO without issue tracker reference | LOW | Becomes permanent tech debt | | God Object | HIGH | Single class with too many responsibilities | | Magic numbers inline | MEDIUM | Unclear intent; maintenance hazard | | Copy-paste logic | MEDIUM | Silent divergence over time | | Catching and re-throwing without context | MEDIUM | Stack traces lose meaning | | Nested ternary operators | MEDIUM | Unreadable; use if/else or switch instead |

---

SOLID Principles Checklist

• Single Responsibility: does this class/function do exactly one thing?
• Open/Closed: extend via composition/interfaces, not inheritance modification?
• Liskov Substitution: can a subtype always replace the base type without breaking callers?
• Interface Segregation: no fat interfaces — clients should not depend on methods they don't use?
• Dependency Inversion: depend on abstractions (interfaces), not concretions?

---

See Also

• @code-reviewer — applies these rules during code review
• @typescript-reviewer, @python-reviewer, etc. — language-specific rules with these as baseline
• @security-reviewer — security-specific standards (OWASP, secrets, crypto)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jmstar85
• Source: jmstar85/oh-my-githubcopilot
• License: MIT
• Homepage: https://www.linkedin.com/in/minsungjung/

Install and usage instructions live in the source repository linked above.