Interactive idea refinement using Socratic method to develop fully-formed designs
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Flatten nested conditionals with early returns or table-driven methods - keep nesting depth under 3 levels
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
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
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Interactive idea refinement using Socratic method to develop fully-formed designs
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Receive and act on code review feedback with technical rigor, not performative agreement or blind implementation
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Comment WHY code exists and non-obvious decisions, not WHAT code does (mechanics)
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Replace arbitrary timeouts with condition polling for reliable async tests
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
TDD for process documentation - test with subagents before writing, iterate until bulletproof
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Validate at every layer data passes through to make bugs impossible
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.