Interactive idea refinement using Socratic method to develop fully-formed designs
The English summary is being prepared. Showing the original description.
Flatten nested conditionals with early returns or table-driven methods - keep nesting depth under 3 levels
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Nested conditionals are hard to understand and error-prone. Flatten them.
Core principle: Nesting depth < 3 levels. Use early returns, table-driven methods, or extracted conditions.
Agents create nested if/else for multi-condition logic:
❌ Nested (baseline):
def calculate_discount(order_amount, is_vip):
if is_vip:
if order_amount > 1000:
return 0.20
elif order_amount > 500:
return 0.15
else:
if order_amount > 1000:
return 0.10
elif order_amount > 500:
return 0.05
return 0.0
Problems: Duplicated logic, hard to see all tiers, adding tier requires finding nesting spot.
✅ All at same level:
def calculate_discount(order_amount, is_vip):
if is_vip and order_amount > 1000: return 0.20
if is_vip and order_amount > 500: return 0.15
if order_amount > 1000: return 0.10
if order_amount > 500: return 0.05
return 0.0
✅ Business rules as data:
DISCOUNT_TIERS = [
(1000, 0.20, 0.10), # min_amount, vip_rate, regular_rate
(500, 0.15, 0.05),
]
def calculate_discount(order_amount, is_vip):
for min_amount, vip_rate, regular_rate in DISCOUNT_TIERS:
if order_amount > min_amount:
return vip_rate if is_vip else regular_rate
return 0.0
When to use: Pricing tiers, status transitions, configuration-driven logic.
✅ Named boolean for clarity:
def is_eligible(user, minimum):
return (user.age >= 18 and user.verified_email and
user.balance > minimum and not user.suspended)
if is_eligible(user, minimum_purchase):
allow_purchase()
When to use: Complex boolean expressions, reused conditions.
| Problem | Solution |
|---|---|
| Nested if/else | Flatten with combined conditions OR table-driven |
| Deep nesting (>3) | Extract inner logic to function |
| Complex boolean | Extract to named function |
| Business rules | Table-driven method |
| Long if/elif chain | Table lookup OR polymorphism |
Baseline showed agents already use these well:
def validate(data):
if not data:
return False, "data required" # Early return
if data.amount <= 0:
return False, "amount must be positive" # Early return
# Main logic here (no nesting)
Keep using this pattern for validation and error cases.
Fix: Flatten or use table-driven.
From baseline:
For complex functions: See skills/keeping-routines-focused - extract when nesting gets deep
For reducing complexity: See skills/architecture/reducing-complexity - simpler control flow = less complexity
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Interactive idea refinement using Socratic method to develop fully-formed designs
The English summary is being prepared. Showing the original description.
Receive and act on code review feedback with technical rigor, not performative agreement or blind implementation
The English summary is being prepared. Showing the original description.
Comment WHY code exists and non-obvious decisions, not WHAT code does (mechanics)
The English summary is being prepared. Showing the original description.
Replace arbitrary timeouts with condition polling for reliable async tests
The English summary is being prepared. Showing the original description.
TDD for process documentation - test with subagents before writing, iterate until bulletproof
The English summary is being prepared. Showing the original description.
Validate at every layer data passes through to make bugs impossible
The English summary is being prepared. Showing the original description.