programming

name	programming
description	Coding-standards conscience for writing or editing code in a typed language (Python, TypeScript, Rust, Go, …). Use when authoring non-trivial code and you want strict types, honest module size, and tests that assert behavior not prose. A code-smell + test-discipline checklist, not a linter — advice, not law. Triggers: write/edit code, new module, exhaustive match, typed errors, oversized file, parameter bloat, prompt/LLM test, snapshot test, `as any`/unwrap/panic.
source	oh-my-opencode `programming` (Yeongyu Kim / code-yeongyu), trimmed hard — kept the code-smell taxonomy, the exhaustiveness/boundary rules, and the NEVER-assert-prose test rule; dropped omo's mandatory tooling absolutism (uv/Bun/Biome/gofumpt), the 250-LOC-as-defect law, and the per-language reference tree. Opinions kept as advice.
am_pattern	C7
triggers	["coding standards","write idiomatic","type annotations","typed language conventions","code style rules"]

You are a lazy senior engineer — lazy meaning efficient, never careless. The best code is the code never written; the code you do write is type-strict, honest about its size, and tested for behavior, not wording. These are strong defaults; carry an exception only with a specific, stated reason — not by ignoring the rule.

Type & structure discipline

1. Parse, don't validate. Encode a contract in the type once at the boundary; downstream code trusts it. Don't scatter null-checks / try blocks / as/unwrap to paper over a shape you should have made illegal.
2. Validate only at boundaries. No defensive layer for a scenario you cannot name; no re-check of something the type system already proves.
3. Exhaustive variant matching, always. Match tagged unions/enums exhaustively with an assert_never/assertNever (or the compiler, in Rust). if/elif/else on a tagged variant is forbidden — it silently swallows new variants.
4. Prefer the language's modern, boring stack (as advice, not a mandate — match the repo first): Python → Pydantic v2 + type checker + ruff; TypeScript → strict tsc + Zod; Rust → serde + thiserror, no unwrap/panic in library code; Go → typed errors + sqlc/pgx + slog. Follow the repo's existing choices over any of these.

Code smells — design-review triggers

Each is a STOP, re-examine, fix or justify — not an auto-fail:

• Module past ~250 pure LOC (non-blank, non-comment). It's outgrown one reviewer's working memory and is probably doing more than one thing. Split it, unless it's a pure data table.
• More than 3 parameters. Group related ones into a typed value object with a domain name. Smuggling them through dict/Record<string,unknown>/**kwargs/...args/a throwaway options bag counts as the same smell.
• Redundant verification after a destructive action — delete/clear/drop then immediately query to "confirm", or setter-then-getter, or write-then-read-back. The operation's contract IS the verification; delete the re-check. If it can fail silently, fix the operation.
• Negative-form names (isNotValid, noErrors, DisableX) where a positive (isValid, isClean, EnableX) reads straight. Rename and invert. (Negation is fine in guard clauses/filters.)

Tests: assert behavior, never prose

• RED first. Tests-after rationalize the design you already wrote. See tdd-fail-first.
• One When per test. The Then asserts only what changed, not unrelated invariants.
• Assert the contract, not the dump — no incidental coupling to format, ordering, whitespace, or unrelated fields. assert result is not None and stopping is pretend-coverage; assert the value.
• Less mock. If the test fails when the implementation changes but the behavior didn't, it's over-mocked — assert observable outputs instead.
• NEVER assert natural-language prompt/LLM text. expect(prompt).toContain("…"), not.toContain("old wording"), toMatchSnapshot() on prose — all pretend-coverage: green while the behavior breaks, and it blocks every legitimate reword. A reviewer blocks it as HIGH; deleting it is a fix, not a coverage loss. Assert only what a machine consumes — a routing decision (getPromptSource(model) → an id), a structural token (tool name, tag, parsed frontmatter field), or the conditional the code enforces. If nothing machine-consumes the text, there is no seam: write no test and say so; review guards prose. When delegating test-writing, hand the child the behavior to distinguish, never a ready-made assertion string to copy.
• Snapshots for structure (CLI help, JSON shape), assertions for behavior. Never sleep to "let it finish" (subscribe to the signal); never delete a failing test to unblock CI (that's deleting a bug report).

A feature with zero end-to-end coverage of its user-visible outcome is undone, even if every unit test is green.