clean-codelisted

# /clean-code — Clean-Code principles while writing This skill is a **set of writing principles**, not a linter. It guides what Claude *types* — naming choices, function size, comment discipline. Formatters handle whitespace; this skill handles judgment. Sources: Bob Martin's *Clean Code*, Hunt/Thomas's *Pragmatic Programmer*, Fowler's *Refactoring* (smells + named techniques). ## Names - **Verbs for functions**, nouns for classes, adjectives or short noun phrases for booleans (`isEmpty`, `hasPaidInvoice`, not `getEmpty`). - **Domain words, not technical words.** `placeOrder` beats `processData`. `Customer` beats `UserDto` in domain code (DTOs belong in adapters anyway). - **No encoding prefixes.** Don't use `I` for interfaces, `m_` for fields, `str` for strings. Modern IDEs make these noise. - **No disinformation.** A `Map<UserId, User>` named `userList` lies. So does a parameter `accountInfo` that's a single string. - **Searchable names.** Avoid single-letter names except in tiny scopes (lambdas, loop counters). - **Pick one word per concept.** `fetch`, `retrieve`, `get` for the same operation across the codebase = three searches instead of one. ## Functions - **One function = one task** at one level of abstraction. - **Short.** ~20 lines is a *smell threshold*, not a hard rule. If a 40-line function is genuinely linear and reads top-to-bottom, leave it. If a 15-line function has three nested ifs, split it. - **Few parameters.** 0-2 is fine, 3 is borde