Clean code naming
Skill lifeodyssey/craftsmanship-skills/skills/clean-code-naming
Agent Skills distilled from Clean Code & Refactoring. Install: npx skills add lifeodyssey/craftsmanship-skills
npx -y skills add lifeodyssey/craftsmanship-skills --skill clean-code-namingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when choosing names for variables, functions, classes, or modules — applies Clean Code naming principles for clear, intention-revealing identifiers
SKILL.md
2.9 KB, as published. Nobody here has run it
Clean Code: Naming
Based on Robert C. Martin's Clean Code, Chapter 2: Meaningful Names.
When to Use This Skill
Trigger on:
- Naming or renaming variables, functions, classes, modules
- Code review flagging unclear identifiers
- Debates about naming conventions
- "What should I call this?" questions
Rules
1. Use Intention-Revealing Names
A name should tell you why it exists, what it does, and how it is used.
# Bad
d = 86400
elapsed_time_in_days = 86400
# Good
SECONDS_PER_DAY = 86400
2. Avoid Disinformation
Don't use names that mean something subtly different than what they represent.
# Bad — list implies specific type, but it could be any collection
account_list = get_accounts()
# Good
accounts = get_accounts()
3. Make Meaningful Distinctions
Don't use noise words that don't add meaning.
# Bad — these names don't distinguish concepts
def copy(a, b): ...
def copy1(source, destination): ...
# Good
def copy(source, destination): ...
4. Use Pronounceable Names
If you can't say it, you can't discuss it.
# Bad
genymdhms = datetime.now()
# Good
generation_timestamp = datetime.now()
5. Use Searchable Names
Single-letter names are hard to search. The length of a name should correspond to its scope.
# Bad — scope is large but name is cryptic
for j in range(len(users)):
if users[j].age > 18:
...
# Good
for user in users:
if user.age > 18:
...
6. Avoid Encodings
Don't prefix names with type information (Hungarian notation) or member prefixes.
# Bad
m_dsc = "description" # member prefix
str_name = "Alice" # type prefix
# Good
description = "description"
name = "Alice"
7. Class Names
Classes and objects should have noun or noun-phrase names. Avoid Manager, Processor, Data, Info.
8. Method Names
Methods should have verb or verb-phrase names. Accessors use get/set, predicates use is/has/can.
9. Don't Be Cute
Choose clarity over humor. whack() < delete(). holy_hand_grenade() < fast_delete().
10. Pick One Word Per Concept
Don't use fetch, retrieve, and get for the same concept. Pick one and stick with it.
11. Add Meaningful Context
Group related variables in a class or prefix consistently when context isn't available from scope alone.
Quick Checklist
- Does the name tell you what it does?
- Can you pronounce it?
- Can you search for it?
- Does it encode unnecessary type information?
- Is there a shorter, clearer alternative?
- Does it follow the project's naming conventions?
Source
Distilled from Clean Code by Robert C. Martin, Chapter 2: Meaningful Names.