code-object-naminglisted

# Code Object Naming ## Why Names Matter Names are not for the compiler—they are for every human and AI that reads, debugs, extends, or maintains the code. Good names: - Speed defect location (~20% faster) - Reduce documentation and comments needed - Reduce misunderstanding-driven errors - Improve LLM comprehension efficiency (up to ~30% fewer tokens wasted) Names are a secondary concern only when the code is broken, untested, unsafe, or undeployable. Once those are true, naming matters. --- ## Diagnostic Workflow ### Step 1 — Diagnose the Name Locate the name on Belshee's naming process scale: | Stage | What it looks like | |---|---| | **Missing / Nonsense** | No name, UUID-style, `tmp`, `data`, `info`, `obj` | | **Honest but Incomplete** | Names one use but the item has broader scope | | **Honest and Complete** | Lists all purposes but is long and unfocused | | **Intention-Revealing** | Clear about *purpose* and carries needed context | | **Domain Abstraction** | Single-purposed, domain-consistent, concerns separated | **Target**: Intention-Revealing or Domain Abstraction. **Acceptable temporary stop**: Honest but Incomplete (never Nonsense). > If you cannot name it well right now, give it an *obviously bad* name > (e.g., `applesauce`, `poop`, `doomed_X`) — easy to search, clearly > temporary, embarrassing enough to remove before commit. --- ### Step 2 — Assign the Right Part of Speech | Code object | Preferred grammar | Examples | |---|---|---| | Variables, par