Naming identifiers: by role, in domain vocabulary, as long as their scope

Goal

A reader understands a function or variable from its name without reading the body, and a search for a term finds exactly the places where it is used.

Prerequisites

A shared domain vocabulary (a glossary in the README or in decision records); a tool that renames safely across the whole project; the language's naming convention, such as PEP 8 for Python or "Effective Go" for Go, accepted as settled.

Steps

1. Name by role and meaning, not by type or mechanism: mahnfrist instead of dt2, offene_rechnungen instead of liste1, nach_kundin_gruppiert instead of dict_result.
2. Match length to scope: a loop index may be called i, while a module constant or a public function needs a full description. Effective Go points out that long names do not automatically make code more readable and that a good doc comment is often worth more than a very long name.
3. Use one word per concept throughout the project: laden or holen or lesen, not all three; use the terms of the domain, not those of the framework.
4. Name booleans as statements (ist_abgelaufen, hat_kinder), functions as a verb or verb phrase (berechne_total, sende_erinnerung), and collections in the plural. Put units in the name where the type does not carry them (timeout_ms, betrag_rappen).
5. Avoid encodings: no type prefixes, and no suffixes such as _v2 or _neu that become false after the next change. PEP 8 forbids the single characters l, O and I as variable names because in some fonts they cannot be told apart from 1 and 0.
6. Follow language conventions for visibility and form: in Go, a capital first letter determines whether a name is exported, and by convention single-method interfaces end in -er (Reader, Writer); in Python, underscores separate words, and a leading underscore marks internal names.
7. If a name needs a comment to be understood, rename it instead of commenting it. When your understanding improves, rename immediately, using tooling and in a separate commit with no other changes.

Expected result

Fewer comments, shorter reviews, searches that find exactly the uses of a term, and code in which domain experts recognize their own concepts.

Limits and test basis

Public API names cannot be changed freely; they deserve more care the first time. Whether identifiers are German or English is a team decision that must be applied consistently; mixed forms (getKundin) are the worst of both. The conventions come from the cited style guides; no measurement is claimed.