Simplify complex conditionals without changing decisions

Flattening nested conditions can broaden eligibility accidentally. A coupon that applies only inside a premium/high-value branch must not become a global rule.

Lab briefing

[!NOTE] Moving a condition outside its parent can broaden eligibility.

Concepts · First task · Evidence checklist · Reset

Learning objectives

• Derive a decision table before rewriting conditions.
• Preserve threshold equality, precedence, discount caps, and error behavior.
• Choose named predicates or guard clauses based on semantics.

Before you start

Prepare 09-conditionals using the setup guide. The primary fixture is ECommercePricingEngine. The loan-approval demo is optional and purely fictional; it is not a credit policy or a system for real financial decisions.

Concepts and use cases

Exercise scenario

PricingEngine.CalculateFinalPrice evaluates membership, seasonal events, coupons, shipping, and category-specific caps. Preserve the current outputs while clarifying one family of conditions.

Task 1 - Establish the decision surface

1. Read ECommercePricingDemo.cs and SecurityTest.cs.

2. Identify User, Coupon, Order, SafeAddDiscount, and category-specific logic.

3. Ask for a rule inventory with source references, not a proposed rewrite yet.

4. Build and run:

   dotnet build ECommercePricingEngine.csproj -m:1 -p:UseSharedCompilation=false
   dotnet run --no-build --project ECommercePricingEngine.csproj
   

5. Record results, including warnings and rejected inputs. Demo scenarios and security-labeled methods are not a comprehensive security or coverage report.

Task 2 - Derive a boundary table

Start with these dimensions, then record the actual expected value from the source and baseline for every selected row:

Do not generate the full Cartesian product blindly. Choose cases that distinguish branches and interactions, then explain the remaining coverage gaps.

Task 3 - Plan one equivalent transformation

Plan a refactor of membership conditions only. Keep coupon order, category caps,
shipping, and public output unchanged. Show how each selected decision-table row
maps to the new structure. Preserve > versus >= exactly. Do not edit yet.

Review short-circuit behavior. A switch can improve readability, but is not evidence that overlapping rules or side effects are preserved.

Task 4 - Implement and validate

1. Ask Agent to implement the reviewed slice with no dependency changes.
2. Compare the decision table against the diff before accepting it.
3. Turn chosen rows into executable assertions using the project’s current entry points or a small characterization harness.
4. Re-run the same build/demo and assertions.
5. Deliberately change one strict comparison to an inclusive comparison; confirm the equality case fails, then restore it.

Verify your work

• Decision-table rows include equality and overlapping conditions.
• Discount caps and shipping rules retain their ordering.
• Invalid inputs retain their documented failure behavior.
• Negative mutation is detected by an executable check.
• No “fewer lines means correct” claim is used as evidence.

Troubleshooting

If a flattened condition produces an extra discount, reconstruct its original parent conditions. If logging changes unexpectedly, inspect early returns. If only happy paths are green, add one failing and one equality case before further refactoring.

Independent practice

Repeat one extraction in the optional LoanApprovalWorkflow copy, using only synthetic data. Document rule equivalence without presenting the demo as a fair, lawful, or production-ready credit decision system.

Reset

Save the decision table and outputs, then restore only the files changed in your disposable copy. Do not overwrite imported reference output with fabricated results.

Official references

• Plan with agents
• C# pattern matching
• C# testing