Code Simplifier

Code Simplifier

A guide for simplifying and refining code while preserving functionality.

When to Use

• Refactor, simplify code, clean up, code review
• After completing a coding task or writing a logical chunk of code
• Cleaning up complex PRs before review
• Refactoring code for better readability and maintainability

Core Principles

1. Preserve Functionality

Never change what the code does - only how it does it.

• All original features, outputs, and behaviors must remain intact
• Test before and after to verify no regressions
• If unsure, ask before refactoring

2. Apply Project Standards

Follow established coding standards from project configuration (CLAUDE.md, .editorconfig, ESLint, etc.):

• Consistent import sorting and organization
• Preferred function styles (arrow vs function keyword)
• Explicit type annotations where required
• Component patterns and naming conventions

3. Enhance Clarity

Simplify code structure by:

• Reducing unnecessary complexity and nesting
• Eliminating redundant code and abstractions
• Improving readability through clear variable and function names
• Consolidating related logic
• Removing unnecessary comments that describe obvious code

Critical Rules:

• Avoid nested ternary operators - prefer switch statements or if/else chains
• Avoid overly compact one-liners - explicit code is often better
• Choose clarity over brevity

4. Maintain Balance

Avoid over-simplification that could:

• Reduce code clarity or maintainability
• Create overly clever solutions that are hard to understand
• Combine too many concerns into single functions
• Remove helpful abstractions that improve organization
• Make the code harder to debug or extend

5. Focus Scope

Only refine code that has been recently modified or touched, unless explicitly instructed to review a broader scope.

Refinement Process

1. Identify the recently modified code sections
2. Analyze for opportunities to improve elegance and consistency
3. Apply project-specific best practices and coding standards
4. Ensure all functionality remains unchanged
5. Verify the refined code is simpler and more maintainable
6. Document only significant changes that affect understanding

Refactoring Patterns

See references/refactoring-patterns.md for common patterns.

Quick Checklist

Before submitting refactored code:

• [ ] All tests pass
• [ ] No functionality changed
• [ ] Code follows project standards
• [ ] No nested ternaries introduced
• [ ] Variable names are clear and descriptive
• [ ] No unnecessary abstractions added
• [ ] Comments updated if logic changed
• [ ] Import statements organized

Example Usage

Trigger phrases:

• "Simplify this code"
• "Make this clearer"
• "Refine this implementation"
• "Clean up this function"
• "Review this PR for readability"

Workflow:

1. Write code → Complete feature 2. Run tests → Verify functionality 3. Apply code-simplifier → Improve clarity 4. Run tests again → Confirm no regressions 5. Submit PR → Ready for review

Done Criteria

• [ ] All tests pass after refactoring
• [ ] No functionality changed
• [ ] Code follows project standards
• [ ] No nested ternaries or overly complex one-liners

Refactoring Patterns

Common refactoring patterns for code simplification.

Table of Contents

• Conditional Simplification
• Function Extraction
• Early Returns
• Loop Optimization
• Error Handling
• Anti-Patterns to Avoid

---

Conditional Simplification

Before: Nested Ternaries (❌)

const status = isActive ? (isPremium ? "premium" : "active") : "inactive";

After: Switch or If/Else (✅)

function getStatus(isActive, isPremium) {
  if (!isActive) return "inactive";
  if (isPremium) return "premium";
  return "active";
}

---

Function Extraction

Before: Long Function (❌)

function processOrder(order) {
  // Validate order
  if (!order.items || order.items.length === 0) {
    throw new Error("Order must have items");
  }
  if (!order.customer) {
    throw new Error("Order must have customer");
  }

  // Calculate total
  let total = 0;
  for (const item of order.items) {
    total += item.price * item.quantity;
  }

  // Apply discount
  if (order.coupon) {
    total = total * (1 - order.coupon.discount);
  }

  return { ...order, total };
}

After: Extracted Functions (✅)

function validateOrder(order) {
  if (!order.items?.length) {
    throw new Error("Order must have items");
  }
  if (!order.customer) {
    throw new Error("Order must have customer");
  }
}

function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

function applyDiscount(total, coupon) {
  if (!coupon) return total;
  return total * (1 - coupon.discount);
}

function processOrder(order) {
  validateOrder(order);
  const subtotal = calculateTotal(order.items);
  const total = applyDiscount(subtotal, order.coupon);
  return { ...order, total };
}

---

Early Returns

Before: Deeply Nested (❌)

function getUserDisplayName(user) {
  if (user) {
    if (user.profile) {
      if (user.profile.displayName) {
        return user.profile.displayName;
      } else {
        return user.email;
      }
    } else {
      return user.email;
    }
  } else {
    return "Anonymous";
  }
}

After: Guard Clauses (✅)

function getUserDisplayName(user) {
  if (!user) return "Anonymous";
  if (!user.profile) return user.email;
  return user.profile.displayName || user.email;
}

---

Loop Optimization

Before: Manual Loop (❌)

const activeUsers = [];
for (let i = 0; i < users.length; i++) {
  if (users[i].isActive) {
    activeUsers.push(users[i].name);
  }
}

After: Array Methods (✅)

const activeUserNames = users
  .filter((user) => user.isActive)
  .map((user) => user.name);

---

Error Handling

Before: Silent Catch (❌)

try {
  const data = JSON.parse(response);
  return data;
} catch (e) {
  // Ignore error
}

After: Explicit Handling (✅)

function parseResponse(response) {
  try {
    return JSON.parse(response);
  } catch (error) {
    console.error("Failed to parse response:", error.message);
    return null;
  }
}

---

Anti-Patterns to Avoid

1. Overly Compact Code

// ❌ Too compact
const r = a
  .filter((x) => x.v > 0)
  .map((x) => ({ ...x, s: x.v * 2 }))
  .reduce((a, b) => a + b.s, 0);

// ✅ Clear and readable
const positiveItems = items.filter((item) => item.value > 0);
const withScores = positiveItems.map((item) => ({
  ...item,
  score: item.value * 2,
}));
const totalScore = withScores.reduce((sum, item) => sum + item.score, 0);

2. Unnecessary Abstraction

// ❌ Over-engineered
class StringUtils {
  static isEmpty(str) {
    return str === '';
  }
}
if (StringUtils.isEmpty(name)) { ... }

// ✅ Simple and direct
if (name === '') { ... }
// or
if (!name) { ... }

3. Magic Numbers

// ❌ Unclear intent
if (status === 3) { ... }

// ✅ Self-documenting
const STATUS_COMPLETED = 3;
if (status === STATUS_COMPLETED) { ... }

4. Dead Code

// ❌ Unused code left in
function processData(data) {
  // Old implementation - keeping for reference
  // const result = oldProcess(data);

  const result = newProcess(data);
  return result;
}

// ✅ Clean
function processData(data) {
  return newProcess(data);
}

---

Language-Specific Patterns

TypeScript

// ❌ Redundant type assertions
const user = getUser() as User;
const name = (user as User).name;

// ✅ Type guards
function isUser(obj: unknown): obj is User {
  return obj !== null && typeof obj === "object" && "name" in obj;
}

const user = getUser();
if (isUser(user)) {
  const name = user.name; // Type-safe
}

Python

# ❌ Verbose conditional
if x == True:
    return True
else:
    return False

# ✅ Direct
return x

React/JSX

// ❌ Unnecessary fragments
return (
  <>
    <div>Content</div>
  </>
);

// ✅ Direct
return <div>Content</div>;

---

Summary

---

Code Review Perspectives

コードレビュー時に確認すべき6つの観点（リファクタリング前後で活用）：

🐛 バグ・論理エラー

• ランタイムエラー、エッジケース、null/undefined 問題
• 境界値、空配列、空文字列の処理

🔒 セキュリティ

• XSS、インジェクション、機密データ露出
• 入力バリデーション、認証・認可チェック

⚡ パフォーマンス

• N+1 クエリ、不要な再レンダリング、メモリリーク
• 計算量の最適化、キャッシュの活用

📖 保守性・可読性

• 命名、コード構造、複雑度
• 関数の責務分離、モジュール化

🧪 テストカバレッジ

• 不足しているテストケース
• エッジケースのテスト

📚 ドキュメント

• コメント、JSDoc、README 更新
• API ドキュメント

Feedback Format

レビュー・リファクタリング結果を以下の形式で整理：

• ❌ Critical: 必須修正（機能に影響）
• ⚠️ Warning: 推奨修正（品質に影響）
• 💡 Suggestion: 改善案（あると良い）
• ✅ Positive: 良い点（維持すべき）