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?

coding-standards