The six rules
- Branch on type with an explicit
if … is_a?— not a clevercase. An ordinaryifreads like a sentence. - Name the thing — don’t make the reader decode a chain of operations held in their head.
- Prefer explicit guard clauses — over nested ternaries and dense one‑liners.
- Use full, intention‑revealing names — expressive enough that naming becomes the documentation’s skeleton.
- Say why in a comment; let the code say what — comments carry constraints the code can’t show.
- One statement per line — let the formatter own the layout.
Shorthand that genuinely clarifies is welcome — the canon lists those cases — and every edit finishes with the end‑of‑edit checklist. The examples are Crystal, because that is what we build with; the rules are about reading, not syntax.