Apply professional naming guidelines to code identifiers — variables, constants, classes, methods, parameters, and collections. Use this skill whenever someone asks how to name something in code, whether a name is good, how to improve a name, what's wrong with an existing name, or how to make code more readable through better naming. Also trigger when someone shares code with names like `foo`, `data`, `temp`, `flag`, `i`, `j`, `manager`, `handler`, `doIt`, `getX`, or names that use abbreviations, numeric suffixes, or type prefixes. This skill consolidates guidelines from multiple sources — Ottenstein, Relf, Lawrie et al., Benlarbi, and others — as presented by Peter Hilton's naming guidelines for professional programmers. Domain-agnostic: applies to any language or codebase.
Identifier names comprise 33% of tokens and 72% of characters in large codebases. Studies confirm that full-word identifiers aid understanding better than abbreviations or single letters. The biggest ROI in code readability is naming — not comments, not documentation.
Most teams acknowledge naming is important but have no written guidelines. This skill provides that foundation.
When reviewing or improving names, work through the applicable category below. Each guideline states the rule, what violation looks like, and how to fix it.
A name must pass all applicable guidelines. Start with Syntax, then Vocabulary, then the type-specific guidelines for the kind of identifier being named.
These govern the structure and format of names, independent of meaning.
Apply standard casing with rigorous consistency. Use language-specific inspection tools to enforce it.
Violations: appleCOUNT, apple_count in a camelCase language.
Never add numbers to distinguish identifiers with the same base name. Replace the number with words that describe the actual difference.
Violations: employee2, result1, config3.
Only use correctly-spelled dictionary words and abbreviations that appear in a dictionary.
Exceptions: id, and documented domain-specific abbreviations.
Spelling mistakes create ambiguity. Abbreviations introduce a different kind of ambiguity — the original author knows which word it stands for, but readers don't.
Violations: acc, pos, char, mod, auth, appCnt, usr, pwd.
Refactoring: Write words out in full. Define abbreviations explicitly for the bounded context.
No exceptions for single-letter names — use dictionary words. Single-letter names introduce maximum ambiguity and are not searchable.
Research finding: "Full-word identifiers lead to the best comprehension; however, in many cases there is no statistical difference between using full words and abbreviations." (The