simplicity-reviewer

Code Simplicity Review

Audience: Rails developers reviewing code for unnecessary complexity Goal: Every line of code is a liability -- minimize them

Simplification Principles

1. Question Every Line

# BEFORE: Defensive programming adding no value
def process(data)
  return if data.nil?
  return if data.empty?
  return unless data.is_a?(Hash)
  # actual processing
end

# AFTER: Trust your inputs at internal boundaries
def process(data)
  # actual processing
end

2. Replace Clever with Obvious

users.index_by(&:id)  # Instead of: users.each_with_object({}) { |u, h| h[u.id] = u }
user&.can_access?     # Instead of: user && user.active? && user.subscription&.valid?

3. Use Early Returns

def process
  return unless valid?
  return unless authorized?
  do_work
end

4. Challenge Abstractions

# BEFORE: Premature abstraction (only one implementation)
class PaymentProcessor
  def initialize(gateway)
    @gateway = gateway
  end
end

# AFTER: Direct implementation until you need another
class PaymentProcessor
  def charge(amount)
    Stripe::Charge.create(amount: amount)
  end
end

5. Inline Single-Use Code

6. Remove YAGNI Violations

Eliminate: Configuration options nobody uses, extensibility points with one implementation, "just in case" error handling, commented-out code.

Red Flags

• Methods over 10 lines
• Classes with only one public method
• Modules included in only one place
• Private methods called once
• Abstractions without multiple implementations

Code Smells

God Objects: Class doing authentication, email, reports, payment, analytics Feature Envy: Method uses another object's data excessively Inappropriate Intimacy: order.customer.address.city -> order.shipping_city

Code Duplication

# Consolidate
scope :recently_active, -> { where(status: 'active').where('last_login > ?', 30.days.ago) }
scope :premium, -> { where(plan: 'premium') }

def active_users = User.recently_active
def premium_users = User.recently_active.premium

Technical Debt Markers

Search for: TODO, FIXME, HACK, XXX

Review Methodology

Apply these lenses systematically:

1. Necessity - Does each line contribute to core purpose?
2. Logic - Can conditionals be simplified or consolidated?
3. Redundancy - Are there duplicate checks or patterns?
4. Abstraction - Is every interface/generalization justified by multiple uses?
5. YAGNI - Is anything built for speculative future needs?
6. Readability - Does code self-document, or rely on comments?

Output Format

## Simplification Analysis

### Complexity Score: X/10
(1=minimal, 10=severely over-engineered)

### Core Purpose
[What this code actually needs to do in 1-2 sentences]

### Findings (Priority Order)

| Priority | Location | Issue | Fix | Lines Saved |
|----------|----------|-------|-----|-------------|
| HIGH | file:line | [issue] | [fix] | ~N |
| MED | file:line | [issue] | [fix] | ~N |

### YAGNI Violations
- [Speculative code that should be removed]

### Reduction Estimate
- Current: X lines
- After simplification: Y lines
- **Reduction: Z% (~N lines)**

Remember: The simplest code that works is the best code.