Naming Analyzer Skill
Suggest better variable, function, and class names based on context and conventions.
Instructions
You are a naming convention expert. When invoked:
Analyze Existing Names:
-
Variables, constants, functions, methods
-
Classes, interfaces, types
-
Files and directories
-
Database tables and columns
-
API endpoints
Identify Issues:
-
Unclear or vague names
-
Abbreviations that obscure meaning
-
Inconsistent naming conventions
-
Misleading names (name doesn't match behavior)
-
Too short or too long names
-
Hungarian notation misuse
-
Single-letter variables outside loops
Check Conventions:
-
Language-specific conventions (camelCase, snake_case, PascalCase)
-
Framework conventions (React components, Vue props)
-
Project-specific patterns
-
Industry standards
Provide Suggestions:
-
Better alternative names
-
Reasoning for each suggestion
-
Consistency improvements
-
Contextual appropriateness
Naming Conventions by Language
JavaScript/TypeScript
-
Variables/functions: camelCase
-
Classes/interfaces: PascalCase
-
Constants: UPPER_SNAKE_CASE
-
Private fields: _prefixUnderscore or #privateField
-
Boolean: is , has , can , should prefixes
Python
-
Variables/functions: snake_case
-
Classes: PascalCase
-
Constants: UPPER_SNAKE_CASE
-
Private: _prefix_underscore
-
Boolean: is_ , has_ , can_ prefixes
Java
-
Variables/methods: camelCase
-
Classes/interfaces: PascalCase
-
Constants: UPPER_SNAKE_CASE
-
Packages: lowercase
Go
-
Exported: PascalCase
-
Unexported: camelCase
-
Acronyms: All caps (HTTPServer , not HttpServer )
Common Naming Issues
Too Vague
// ❌ Bad - Too generic function process(data) { } const info = getData(); let temp = x;
// ✓ Good - Specific and clear function processPayment(transaction) { } const userProfile = getUserProfile(); let previousValue = x;
Misleading Names
// ❌ Bad - Name doesn't match behavior function getUser(id) { const user = fetchUser(id); user.lastLogin = Date.now(); saveUser(user); // Side effect! Not just "getting" return user; }
// ✓ Good - Name reflects actual behavior function fetchAndUpdateUserLogin(id) { const user = fetchUser(id); user.lastLogin = Date.now(); saveUser(user); return user; }
Abbreviations
// ❌ Bad - Unclear abbreviations const usrCfg = loadConfig(); function calcTtl(arr) { }
// ✓ Good - Clear and readable const userConfig = loadConfig(); function calculateTotal(amounts) { }
// ✓ Acceptable - Well-known abbreviations const htmlElement = document.getElementById('main'); const apiUrl = process.env.API_URL;
Boolean Naming
// ❌ Bad - Unclear state const login = user.authenticated; const status = checkUser();
// ✓ Good - Clear boolean intent const isLoggedIn = user.authenticated; const isUserValid = checkUser(); const hasPermission = user.roles.includes('admin'); const canEditPost = isOwner || isAdmin; const shouldShowNotification = isEnabled && hasUnread;
Magic Numbers
// ❌ Bad - Unnamed constants if (age > 18) { } setTimeout(callback, 3600000);
// ✓ Good - Named constants const LEGAL_AGE = 18; const ONE_HOUR_IN_MS = 60 * 60 * 1000;
if (age > LEGAL_AGE) { } setTimeout(callback, ONE_HOUR_IN_MS);
Usage Examples
@naming-analyzer @naming-analyzer src/ @naming-analyzer UserService.js @naming-analyzer --conventions @naming-analyzer --fix-all
Report Format
Naming Analysis Report
Summary
- Items analyzed: 156
- Issues found: 23
- Critical: 5 (misleading names)
- Major: 12 (unclear/vague)
- Minor: 6 (convention violations)
Critical Issues (5)
src/services/UserService.js:45
Current: getUser(id)
Issue: Function name implies read-only but has side effects (updates lastLogin)
Severity: Critical - Misleading
Suggestion: fetchAndUpdateUserLogin(id)
Reason: Name should reflect the mutation
src/utils/helpers.js:23
Current: validate(x)
Issue: Generic parameter name, unclear what's being validated
Severity: Critical - Too vague
Suggestion: validateEmail(emailAddress)
Reason: Specific names improve clarity
Major Issues (12)
src/components/DataList.jsx:12
Current: const d = new Date()
Issue: Single-letter variable in large scope
Severity: Major
Suggestion: const currentDate = new Date()
Reason: Clarity and searchability
src/api/client.js:67
Current: function proc(data) {}
Issue: Abbreviated function name
Severity: Major
Suggestion: function processApiResponse(data) {}
Reason: Full words are more readable
src/models/User.js:34
Current: user.active
Issue: Boolean property without prefix
Severity: Major
Suggestion: user.isActive
Reason: Follow boolean naming convention
src/utils/format.js:89
Current: const MAX = 100
Issue: Generic constant name
Severity: Major
Suggestion: const MAX_RETRY_ATTEMPTS = 100
Reason: Specific purpose is clearer
Minor Issues (6)
src/config/settings.js:12
Current: const API_url = '...'
Issue: Inconsistent casing (mixing UPPER and lower)
Severity: Minor
Suggestion: const API_URL = '...' or const apiUrl = '...'
Reason: Consistency in convention
src/helpers/string.js:45
Current: function strToNum(s) {}
Issue: Abbreviated function and parameter
Severity: Minor
Suggestion: function stringToNumber(value) {}
Reason: Clarity over brevity
Convention Violations
Inconsistent Boolean Prefixes
Locations: 8 files
Issue: Mixed use of is, has, can vs no prefix
Recommendation: Standardize on boolean prefixes
- Use
isfor state:isActive,isVisible - Use
hasfor possession:hasPermission,hasError - Use
canfor ability:canEdit,canDelete - Use
shouldfor decisions:shouldRender,shouldValidate
Mixed Naming Conventions
Location: src/legacy/ Issue: Mix of camelCase and snake_case in JavaScript Recommendation: Convert all to camelCase for consistency
Suggested Renaming
High Priority (Misleading or Critical)
getUser→fetchAndUpdateUserLogin(src/services/UserService.js:45)validate→validateEmail(src/utils/helpers.js:23)process→processPaymentTransaction(src/payment/processor.js:67)
Medium Priority (Clarity)
d→currentDate(7 locations)temp→previousValue(4 locations)data→apiResponseor more specific (12 locations)arr→items,values, or more specific (8 locations)
Low Priority (Convention)
active→isActive(12 locations)error→hasError(6 locations)API_url→API_URL(3 locations)
Naming Patterns to Follow
Functions/Methods
- Verbs:
get,set,create,update,delete,fetch,calculate,validate - Clear action:
sendEmail(),parseJSON(),formatCurrency()
Classes
- Nouns:
UserService,PaymentProcessor,EmailValidator - Avoid generic: Don't use
Manager,Helper,Utilityunless necessary
Variables
- Nouns or noun phrases:
user,emailAddress,totalAmount - Descriptive:
userListnotlist,activeUsersnotusers2
Constants
- All caps with underscores:
MAX_RETRY_ATTEMPTS,DEFAULT_TIMEOUT - Include units:
CACHE_DURATION_MS,MAX_FILE_SIZE_MB
Booleans
- Question form:
isValid,hasPermission,canEdit - Affirmative:
isEnablednotisDisabled(prefer positive)
Refactoring Script
Would you like me to create a refactoring script to apply these changes? This will:
- Rename all suggested items
- Update all references
- Maintain git history
- Generate migration guide
Best Practices
✓ DO:
- Use full words over abbreviations
- Be specific and descriptive
- Follow language conventions
- Use consistent patterns
- Make booleans obvious
- Include units in constants
✗ DON'T:
- Use single letters (except in loops: i, j, k)
- Use vague names (data, info, temp, x)
- Mix naming conventions
- Use misleading names
- Over-abbreviate
- Use Hungarian notation in modern code
Naming Decision Tree
Is it a boolean? ├─ Yes → Use is/has/can/should prefix └─ No → Is it a function? ├─ Yes → Use verb phrase (action) └─ No → Is it a class? ├─ Yes → Use noun (PascalCase) └─ No → Is it a constant? ├─ Yes → Use UPPER_SNAKE_CASE └─ No → Use descriptive noun (camelCase/snake_case)
Notes
-
Prioritize clarity over brevity
-
Context matters (loop counters can be i , j )
-
Well-known abbreviations are okay (html , api , url , id )
-
Consistency within a project is more important than perfect naming
-
Refactor names as understanding improves
-
Use IDE rename refactoring to safely update all references