Master Naming Suite

A comprehensive skill for naming things in software — covering variable naming conventions, function naming patterns, file and directory naming, API endpoint naming, database column naming, and team naming standards across different languages and frameworks.

When to Use This Skill

Choose Master Naming Suite when you need to:

• Establish naming conventions for a new codebase
• Refactor inconsistent naming across a project
• Choose clear names for complex functions or variables
• Design API endpoint naming strategies
• Create naming guidelines for a development team

Consider alternatives when:

• You need code style formatting (use a linter/formatter skill)
• You need code documentation (use a documentation skill)
• You need API design beyond naming (use an API design skill)

Quick Start

Copy
# Get naming suggestions
claude "Suggest better names for these variables in a user authentication module: d (data), res (result), tmp (temporary value), flag (boolean), cb (callback)"

Copy
# Naming Improvements

| Current | Problem              | Better Name            | Why                          |
|---------|---------------------|------------------------|------------------------------|
| d       | Single letter, vague | userData / loginPayload | Describes what the data is   |
| res     | Ambiguous abbreviation| authResult / loginResponse | Distinguishes from HTTP response |
| tmp     | No context          | pendingToken / unverifiedEmail | Names the temporary thing |
| flag    | Generic boolean     | isAuthenticated / hasValidSession | Describes what it flags |
| cb      | Cryptic abbreviation| onAuthComplete / handleLoginResult | Describes the callback's purpose |

## Naming Rules Applied
1. Names should reveal intent, not implementation
2. Boolean names start with is/has/can/should
3. Callbacks describe the event, not the mechanism
4. Avoid abbreviations unless universally known (URL, ID, HTTP)

Core Concepts

Language-Specific Conventions

Language	Variables	Functions	Classes	Constants	Files
JavaScript	camelCase	camelCase	PascalCase	UPPER_SNAKE	kebab-case.js
TypeScript	camelCase	camelCase	PascalCase	UPPER_SNAKE	kebab-case.ts
Python	snake_case	snake_case	PascalCase	UPPER_SNAKE	snake_case.py
Go	camelCase	PascalCase*	PascalCase	camelCase	snake_case.go
Rust	snake_case	snake_case	PascalCase	UPPER_SNAKE	snake_case.rs
Ruby	snake_case	snake_case	PascalCase	UPPER_SNAKE	snake_case.rb

*Go uses PascalCase for exported, camelCase for unexported

Function Naming Patterns

Copy
## Function Name Formulas

### Actions: verb + noun
- getUser(), createOrder(), deleteSession()
- fetchUserProfile(), validateEmail(), parseConfig()

### Transformations: source + To + target
- celsiusToFahrenheit(), jsonToXml(), stringToDate()

### Predicates (return boolean): is/has/can/should + condition
- isValid(), hasPermission(), canEdit(), shouldRetry()

### Event Handlers: on/handle + event
- onSubmit(), handleClick(), onAuthSuccess()

### Factory Functions: create/make/build + noun
- createUser(), makeConnection(), buildQuery()

### Anti-Patterns to Avoid
❌ processData() — too vague (process how?)
❌ doStuff() — meaningless
❌ manager() — noun, not a verb
❌ handleIt() — what is "it"?
❌ temp() — what is temporary?

API Endpoint Naming

Copy
## RESTful Endpoint Naming

### Pattern: /resource/{id}/sub-resource
GET    /users              — List users
GET    /users/123          — Get user 123
POST   /users              — Create user
PUT    /users/123          — Update user 123
DELETE /users/123          — Delete user 123
GET    /users/123/orders   — List user 123's orders

### Rules
1. Use plural nouns: /users not /user
2. Use kebab-case: /user-profiles not /userProfiles
3. Use nouns, not verbs: /users not /getUsers
4. Nest for relationships: /users/123/orders
5. Use query params for filtering: /users?role=admin

### Anti-Patterns
❌ /getUsers, /createUser — verbs in URLs
❌ /user_profiles — snake_case in URLs
❌ /Users — PascalCase in URLs
❌ /users/get-all — action in path

Configuration

Parameter	Description	Example
language	Primary programming language	"typescript"
convention	Naming convention standard	"airbnb" / "google"
max_length	Maximum name length	40 characters
abbreviations	Allowed abbreviations	["id", "url", "http"]
prefix_style	Boolean prefix style	"is" / "has"

Best Practices

1. Name things by what they represent, not how they're implemented — userList is better than userArray. priceInCents is better than priceInt. Implementation changes; meaning stays. When you refactor from an array to a Set, userList still makes sense but userArray becomes a lie.

2. Use consistent verb vocabulary across the codebase — Pick one: get/fetch/retrieve — not all three. Pick one: create/make/build — not all three. Document the chosen verbs in a style guide. Inconsistency forces developers to guess which verb was used where.

3. Don't abbreviate unless the abbreviation is more recognizable than the full word — URL, HTTP, ID — everyone knows these. usr, btn, mgr — these save a few characters but cost readability. If you'd need to explain the abbreviation to a new team member, spell it out.

4. Make the name proportional to the scope — Loop variables can be short (i, j). Module-level constants should be descriptive (MAX_RETRY_ATTEMPTS). A variable used in 3 lines can be count. A variable used across 100 lines needs activeUserSessionCount.

5. Rename without hesitation when you find a better name — Good naming is iterative. When you realize data should be userProfile, rename it immediately. Modern IDEs make project-wide renames safe and instant. The cost of a bad name compounds every time someone reads it.

Common Issues

Team members use different names for the same concept — One developer calls it user, another calls it account, a third calls it profile. Maintain a domain glossary that defines the canonical name for each concept and enforce it in code reviews.

Names become outdated as code evolves — A function named sendEmail that now also sends SMS and push notifications is misleading. When behavior changes, rename to match: sendNotification. Old names that don't match current behavior are worse than vague names.

Hungarian notation and type prefixes clutter the code — strName, intAge, boolIsActive — these prefixes duplicate information that the type system already provides. Modern languages with strong type systems make type prefixes unnecessary noise. Let the types speak for themselves.