Smells

---
name: smells
description: Analyze a class or module for code smells and produce a prioritized refactoring plan. Use when the user asks for code smell analysis, says `/smells`, or runs `/refactor:smells`.
metadata:
  legacy-name: refactor:smells
---

Analyze the provided class for code smells and create a refactoring plan.

## Usage
```
/smells $ARGUMENTS
```

## Analysis Output

### 📊 Code Smell Analysis for: $ARGUMENTS

#### 🔍 Top 5 Code Smells Detected:

1. **Poor Naming Conventions**
   - Generic variable names (data, temp, obj, result)
   - Non-descriptive method names (process, handle, do)
   - Inconsistent naming patterns
   - **Fix**: Rename to domain-specific terms that describe purpose

2. **Long Method**
   - Methods exceeding 20-30 lines
   - Multiple responsibilities in single method
   - Difficult to test and understand
   - **Fix**: Extract smaller, focused methods with single responsibilities

3. **Large Class (God Object)**
   - Too many responsibilities in one class
   - High number of instance variables
   - Violates Single Responsibility Principle
   - **Fix**: Split into smaller, cohesive classes

4. **Duplicate Code**
   - Copy-pasted logic across methods
   - Similar patterns with slight variations
   - **Fix**: Extract common logic into reusable methods

5. **Feature Envy**
   - Methods that use data from other classes more than their own
   - Excessive getter/setter calls to another object
   - **Fix**: Move method to the class it's most interested in

### 📋 Refactoring Plan

#### Phase 1: Name Refactoring (No Behavior Changes)
- [ ] Identify all poorly named variables, methods, and fields
- [ ] Map current names to descriptive alternatives
- [ ] Ensure naming follows language conventions:
  - Java/JavaScript: camelCase for methods/variables, PascalCase for classes
  - Python: snake_case for functions/variables, PascalCase for classes
- [ ] Update all references throughout codebase
- [ ] Run tests to ensure no behavioral changes

#### Phase 2: Structure Improvements
- [ ] Address long methods by identifying extraction points
- [ ] Plan class decomposition for God Objects
- [ ] Identify duplicate code patterns for consolidation
- [ ] Map feature envy methods to their proper homes

#### Phase 3: Implementation Order
1. **Start with naming** - Low risk, high readability impact
2. **Extract methods** - Reduce complexity incrementally
3. **Remove duplication** - Create reusable components
4. **Reorganize classes** - Move methods to appropriate classes
5. **Split large classes** - Final structural improvements

### 🎯 Success Criteria
- All tests pass after each refactoring step
- Code coverage remains the same or improves
- Cyclomatic complexity reduced
- Improved readability scores
- No behavioral changes introduced

### ⚠️ Risk Mitigation
- Create comprehensive test suite before refactoring
- Use version control for easy rollback
- Refactor in small, reviewable commits
- Document all name mappings
- Review with team before major structural changes

## Example Name Refactorings
```
// Before
getData() → fetchCustomerPurchaseHistory()
processItems() → calculateMonthlyRevenue()
userObj → customerProfile
temp → filteredTransactions
data → invoiceRecords
doStuff() → validatePaymentCredentials()
```

## Next Steps
1. Review the identified code smells
2. Prioritize based on impact and risk
3. Begin with Phase 1 naming refactors
4. Proceed incrementally through the plan
5. Measure improvements after each phase