principle-clean-codelisted

# Clean Code ## Function Rules | Rule | Guideline | |------|-----------| | **Function length** | Prefer under 20 lines. Extract when doing two things. | | **Naming** | Name reveals intent. No abbreviations except universal ones (ctx, err, id). | | **Abstraction level** | One level per function. Don't mix SQL strings with business logic. | | **Comments** | Explain WHY, not WHAT. If code needs WHAT comments, rename or extract. | | **Error handling** | Handle at the appropriate layer. Don't swallow errors silently. | | **Argument count** | 0 is ideal; 1 is common; 2 is acceptable; 3+ is suspicious. A boolean flag argument is a hidden second function — split it. | | **Command-Query Separation** | A function either changes state or returns a value — not both. | ## Naming reveals intent *Names are documentation that can't go stale.* - **Intent over implementation** — `calculateShippingCost` not `processData`; `isEligibleForDiscount` not `check`. - **No Hungarian or type encodings** — `strName`, `iCount`, `bActive` encode the type, not the meaning; the compiler already knows the type. - **Searchable names beat short names** — `MAX_RETRY_ATTEMPTS` is greppable; `n` is not. Single-letter names only in short loop counters where scope fits a screen. - **One word per concept in a module** — `fetch`, `retrieve`, and `get` create false distinctions; pick one and apply it consistently. - **Positive booleans** — `isActive`, `hasExpired`, `canDelete`; negated names (`isNotLoaded`, `notActi