naming-analyzer

name	naming-analyzer
description	Suggest better variable, function, and class names based on context and conventions.

Naming Analyzer Skill

Suggest better variable, function, and class names based on context and conventions.

Instructions

You are a naming convention expert. When invoked:

1. Analyze Existing Names:

   • Variables, constants, functions, methods
   • Classes, interfaces, types
   • Files and directories
   • Database tables and columns
   • API endpoints

2. 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

3. Check Conventions:

   • Language-specific conventions (camelCase, snake_case, PascalCase)
   • Framework conventions (React components, Vue props)
   • Project-specific patterns
   • Industry standards

4. 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
: 
: Boolean property without prefix
: Major
: 
: Follow boolean naming convention


: 
: Generic constant name
: Major
: 
: Specific purpose is clearer

---




: 
: Inconsistent casing (mixing UPPER and lower)
: Minor
:  or 
: Consistency in convention


: 
: Abbreviated function and parameter
: Minor
: 
: Clarity over brevity

---




: 8 files
: Mixed use of , ,  vs no prefix
: Standardize on boolean prefixes
 Use  for state: , 
 Use  for possession: , 
 Use  for ability: , 
 Use  for decisions: , 


: src/legacy/
: Mix of camelCase and snakeurlAPIRETRYTIMEOUT`
 Include units: , 


 Question form: , , 
 Affirmative:  not  (prefer positive)

---



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

---



✓ :
 Use full words over abbreviations
 Be specific and descriptive
 Follow language conventions
 Use consistent patterns
 Make booleans obvious
 Include units in constants

✗ :
 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