1.A Recipe Card for Someone Else

The Problem in Real Life

Code Only Its Author Understands vs. Code Anyone Can Change Safely

Readable Code, Naming Conventions and Code Organisation

• Names that say what something is: a good name answers "what is this?" without the reader looking anywhere else: ticketCount instead of c, basePrice instead of b, calculateGroupPrice instead of f. Longer is fine if it's clearer. Avoid abbreviations only you know (cnt, prc, usr) and vague words (data, info, temp, handle).
• Naming conventions — everyone writes the same way: each language has its own conventions. In JavaScript/TypeScript: camelCase for variables and functions (basePrice), PascalCase for classes and types (PriceRule), UPPER_SNAKE_CASE for fixed constants (MAX_GROUP_SIZE). Python uses snake_case for variables and functions. Database columns are often snake_case (Act 13). Follow your project's existing style — consistency beats personal taste.
• Names by kind of thing: booleans read like yes/no questions: isStudent, hasDiscount, canRefund. Functions start with a verb: calculateTotal, sendReminder, findOrderById. Collections are plural: seats, orders.
• Named constants instead of magic numbers: price * 0.85 hides its meaning. const GROUP_DISCOUNT = 0.15; and price * (1 - GROUP_DISCOUNT) explains itself, and if the discount changes, there's exactly one place to edit.
• Small functions that do one thing: if you need the word "and" to describe what a function does, it probably does too much. Split the 140-line function into applyGroupDiscount, applyStudentDiscount, applyEarlyBirdPrice and one short function that calls them in order. Each piece is easy to read, name and test (Act 17).
• Early returns instead of deep nesting: five levels of if inside if are hard to follow. Handle the special cases first and return early, so the main path reads straight down.
• Code organisation — things that change together live together: group code by feature (src/pricing/, src/orders/) rather than scattering one feature across many folders. Keep each file focused on one job. Follow the project's existing structure (Act 16).

function f(a, b, c) {
  let t = a * b;
  if (a >= 10) {
    t = t * 0.85;
    if (c) {
      t = t * 0.9;
    }
  }
  return t;
}

const GROUP_MIN_SIZE = 10;
const GROUP_DISCOUNT = 0.15;    // 15% off for groups of 10 or more
const STUDENT_DISCOUNT = 0.10;  // extra 10% for student groups

function calculateGroupPrice(ticketCount, basePrice, isStudent) {
  const fullPrice = ticketCount * basePrice;
  if (ticketCount < GROUP_MIN_SIZE) {
    return fullPrice;                     // early return: not a group
  }

  const priceAfterGroupDiscount = fullPrice * (1 - GROUP_DISCOUNT);
  return isStudent
    ? priceAfterGroupDiscount * (1 - STUDENT_DISCOUNT)
    : priceAfterGroupDiscount;
}