Writing Clean Code

// BAD
Integer d = 30;
if (x > d) { ... }

// GOOD
Integer daysOverdue = 30;
if (accountAge > daysOverdue) { ... }

1. // BAD — a label for the unclear version.
2. Integer d = 30; — d compiles fine, but a reader has to guess what it means.
3. if (x > d) { ... } — same problem with x.
4. (blank line)
5. // GOOD — a label for the clear version.
6. Integer daysOverdue = 30; — daysOverdue reads almost like English.
7. if (accountAge > daysOverdue) { ... } — the whole condition is now self-explanatory.

Clear names are the single cheapest way to make code easier to understand.

// BAD: one method doing three unrelated jobs
public void processOrder(Order__c order) {
    // validate the order
    if (order.Total__c <= 0) { return; }
    // calculate tax
    order.Tax__c = order.Total__c * 0.15;
    // send a confirmation email
    Messaging.sendEmail(...);
}

1. // BAD: one method doing three unrelated jobs — the label for what follows.
2. public void processOrder(Order__c order) { — one method, about to do three unrelated jobs.
3. // validate the order — job one: validation.
4. if (order.Total__c <= 0) { return; } — the validation logic.
5. // calculate tax — job two: calculation.
6. order.Tax__c = order.Total__c * 0.15; — the calculation logic.
7. // send a confirmation email — job three: notification.
8. Messaging.sendEmail(...); — the notification logic.
9. } — closes the method.

This mirrors the refactor from Module 12's "Review and Refactor" lesson: processOrder is doing validation, calculation, and notification all at once. Splitting it into isValidOrder(), calculateTax(), and sendConfirmation() — each with one clear job — makes each piece independently readable, testable, and reusable.

if (isEligibleForDiscount(customer) && cartTotal >= minimumForFreeShipping) {
    applyFreeShipping(order);
}

1. if (isEligibleForDiscount(customer) && cartTotal >= minimumForFreeShipping) { — read out loud: "if the customer is eligible for a discount and the cart total is at least the minimum for free shipping."
2. applyFreeShipping(order); — "...apply free shipping."
3. } — closes the if.

It reads like a sentence describing the actual business rule — a strong sign the names and structure are doing their job. If a piece of code makes you stumble reading it aloud, that's usually a sign it needs clearer names or restructuring.