Extract Variable: Solve the Big Sum with Small Named Steps

The Big Maths Sum and the Rough Paper ✏️

It is Monday morning maths period in Class 8B. Mrs. Verma writes a monster problem on the board: "A shop sells a school bag for Rs. 850 with 12% discount, plus a water bottle for Rs. 240 with 5% discount, and then 18% tax is added on the total. What is the final bill?"

Two students attack it in two different ways.

Raju tries to be a hero. He wants to finish first and show off. He writes one gigantic line in his copy: 850 - 850×12/100 + 240 - 240×5/100 + (850 - 850×12/100 + 240 - 240×5/100)×18/100 = ? Look at that line carefully. The same discount calculation appears twice, because the tax needs the same total again. Halfway through, Raju loses track of which bracket belongs where. He makes a mistake in the second copy of the discount — writes 15 instead of 12 — gets a wrong answer, and cannot even find where it went wrong, because the whole sum is one tangled rope. Mrs. Verma circles the answer in red. Raju stares at his own line and honestly cannot read it any more.

Meena sits two benches away and does what Mrs. Verma always says: show your working in small steps. On rough paper she writes:

• Bag price after discount = 850 − 102 = 748
• Bottle price after discount = 240 − 12 = 228
• Total before tax = 748 + 228 = 976
• Tax = 18% of 976 = 175.68
• Final bill = 976 + 175.68 = 1151.68

Each line has a small name and a small job. If any line is wrong, she can spot it in seconds. Mrs. Verma can follow her thinking and give marks for every correct step, even if the last line slipped. Even Meena-of-next-week can reread it and understand. And notice: Meena never computed anything twice. "Total before tax" was written once and reused for both the tax line and the final line. Raju's double-copy mistake is impossible in Meena's style.

Code has Rajus and Meenas too. Some functions hold one enormous expression — brackets inside brackets, conditions inside arithmetic — that nobody can read. The Extract Variable refactoring turns Raju's one-line monster into Meena's clear steps. And remember our golden line: refactoring means improving the inside of code without changing what it does outside. The final bill stays Rs. 1151.68; only the readability changes. Keep Meena's rough paper in mind — every section below is just that paper, translated into code.

What is Extract Variable?

The plain definition:

Take one meaningful piece of a complicated expression. Put that piece into a new local variable. Give the variable a name that says what the value means. Replace the piece in the big expression with the variable. Repeat until the big expression reads like a sentence.

The big line becomes several small lines, and each small line carries a label, exactly like Meena's rough work.

A note about the name. In Martin Fowler's Refactoring 1st edition (1999), this technique was called Introduce Explaining Variable — a beautiful name, because the variable's only job is to explain. In the 2nd edition (2018) he renamed it Extract Variable, to match the family naming of Extract Function. Its inverse also got renamed: Inline Temp (1st edition) became Inline Variable (2nd edition). So if a book says "explaining variable," a website says "Extract Variable," and an IDE says "Introduce Variable" — relax, they are all the same friendly refactoring.

Fowler adds one sharp question to ask before extracting: does this name make sense only inside this function, or in a wider context too? If the meaning is purely local, a variable is perfect. If other functions also need the idea, prefer extracting a function instead — more on that stepping stone later.

The whole topic, on one revision map:

When Do We Need It? 🔍

Watch for these signs. Each one is Raju's giant line, wearing a different shirt.

1. One expression is trying to say too much. Arithmetic, conditions, and method chains packed into a single line. You must solve operator precedence in your head just to know what is being decided. Dense lines like this are a big reason behind the Long Method smell — long methods are often long in width, not just height.
2. You wrote a comment to explain a formula. A comment like // price after discount above a bare expression is the Comments smell whispering: give me a name instead. priceAfterDiscount as a variable can never go out of date; the comment can.
3. A complex if condition. if (platform.includes("Mac") && browser.includes("IE") && resize > 0) makes readers squint. Pull each part into a named boolean and the if becomes an English sentence. (Doing this for whole conditionals is the cousin refactoring Decompose Conditional.)
4. You cannot debug the middle of a calculation. Breakpoints and watch windows attach to variables. When everything is one expression, you cannot ask the debugger "what was the surcharge?" because the surcharge has no name. After extraction, every step is inspectable — every line of Meena's rough work is checkable.
5. The same sub-expression appears twice in one expression. Extract it once, use the variable twice — duplication inside the line disappears too. This is exactly the trap Raju fell into: he copied the discount maths twice and the copies drifted apart.

What hides inside a typical monster line? Slice one open and you usually find several different business ideas squeezed into one breath:

Each slice deserves its own named line. Discount maths becomes bagPriceAfterDiscount. The tax rule becomes taxableAmount and TAX_MULTIPLIER. The delivery rule becomes qualifiesForFreeDelivery. The bulk offer becomes bulkDiscount. Four slices, four named steps, one readable return line.

There is also a lovely bonus: Extract Variable is a stepping stone. Once the named variables make a block's inputs and outputs visible, you often realise the whole block can become its own method via Extract Method. First name the steps, then maybe promote the steps.

College corner: Why do dense expressions hurt so much? Cognitive science gives a clean answer: working memory. Humans can hold roughly four to seven "chunks" of information at once (Miller's 7±2, later revised downward by Cowan to about four). Parsing (a - a*d/100 + (b - b*e/100)) * (1 + t/100) forces you to track operands, precedence, and bracket depth simultaneously — easily a dozen mental items. A named variable collapses an entire sub-tree of the expression into one chunk: totalBeforeTax. This is also why modern static-analysis tools measure cognitive complexity (SonarSource's metric) and expression nesting depth, not just line counts — and why style guides limit boolean operators per condition. Extract Variable is the direct, mechanical way to drive those metrics down: every extraction removes one level of nesting from the reader's mental parse tree.

Before and After at a Glance

A shop's billing code, in Raju style and then in Meena style.

// BEFORE: one expression trying to say everything
function finalBill(bag: Item, bottle: Item): number {
  return (
    (bag.price - (bag.price * bag.discountPct) / 100 +
      (bottle.price - (bottle.price * bottle.discountPct) / 100)) *
    (1 + 18 / 100)
  );
}

// AFTER: rough-paper steps with names
function finalBill(bag: Item, bottle: Item): number {
  const bagPriceAfterDiscount =
    bag.price - (bag.price * bag.discountPct) / 100;
  const bottlePriceAfterDiscount =
    bottle.price - (bottle.price * bottle.discountPct) / 100;
  const totalBeforeTax = bagPriceAfterDiscount + bottlePriceAfterDiscount;
  const TAX_RATE = 0.18;
  return totalBeforeTax * (1 + TAX_RATE);
}

The after version has more lines — and that is fine! We are not playing "shortest code wins." We are playing "fastest honest understanding wins." Each const is one line of Meena's rough work.

The rhythm of the refactoring, in one line of arrows:

And here is the part students love: extraction makes the code checkable step by step, exactly the way Mrs. Verma checks Meena's copy. Each named line can be confirmed on its own before moving to the next:

Replace "Meena" with your function and "Teacher" with your debugger's watch window, and that diagram is literally how you will troubleshoot billing bugs for the rest of your career.

Step-by-Step, the Safe Way 🪜

Let us do one extraction in slow motion, the professional way, with the code shown at each stage. Starting point:

function deliveryCharge(order: Order): number {
  return order.weightKg * 12 +
    (order.city === "metro" ? 0 : 40) +
    (order.total > 999 ? 0 : 30);
}

Three ideas hide in this line: a weight charge, an outstation surcharge, and a small-order fee. Let us name them one at a time.

Step 1 — Check the sub-expression has NO side effects. Evaluating order.weightKg * 12 must not change anything — no printing, no saving, no counter increase. Pure calculation only. (If it had side effects, extracting could change when the effect happens, and then we would be changing behaviour — not refactoring any more.) Ours is pure. Safe.

Step 2 — Declare a new immutable variable and assign the sub-expression to it. Use const in TypeScript (or final in Java, readonly where available). Immutable, because an explaining variable should be a fact, not something that changes later. Meena never crosses out a rough-work line and writes a new value over it.

function deliveryCharge(order: Order): number {
  const weightCharge = order.weightKg * 12;   // new line
  return order.weightKg * 12 +                // original untouched so far
    (order.city === "metro" ? 0 : 40) +
    (order.total > 999 ? 0 : 30);
}

Step 3 — Name it after what the value MEANS, not how it is computed. weightCharge ✔. weightTimesTwelve ✘ — that name just repeats the formula and explains nothing. A quick test of name quality:

Step 4 — Replace the occurrence in the big expression with the variable.

function deliveryCharge(order: Order): number {
  const weightCharge = order.weightKg * 12;
  return weightCharge +
    (order.city === "metro" ? 0 : 40) +
    (order.total > 999 ? 0 : 30);
}

Step 5 — Compile and run the tests. The charge for every order must be exactly what it was before. Green? Continue.

Step 6 — If the same sub-expression appears more than once, replace every copy. Ours appears once, but when a formula repeats inside one expression, this step also removes duplication — two birds, one stone. Replacing only some copies is the classic careless mistake; the leftover copy and the variable then drift apart, Raju-style.

Step 7 — Repeat for the next confusing piece. Two more rounds, testing after each:

function deliveryCharge(order: Order): number {
  const weightCharge = order.weightKg * 12;
  const outstationSurcharge = order.city === "metro" ? 0 : 40;
  const smallOrderFee = order.total > 999 ? 0 : 30;
  return weightCharge + outstationSurcharge + smallOrderFee;
}

Read that return line aloud: "delivery charge is weight charge plus outstation surcharge plus small order fee." It is a sentence now. And in a debugger you can watch all three values separately — when a customer complains about a wrong charge, you will see in seconds which step produced the wrong number.

The life of one extraction, drawn as states. Note that the side-effect check is the gatekeeper at the very start:

A Bigger Real-Life Example: The School Shop Bill 🏪

Time to code the maths-period story completely. The school shop has a billing function written Raju-style. It handles discounts, a bulk offer, tax, and free delivery — all in one breath.

interface ShopOrder {
  bagPrice: number;
  bagDiscountPct: number;
  bottlePrice: number;
  bottleDiscountPct: number;
  quantitySets: number;
  isSchoolMember: boolean;
}
 
// BEFORE: Raju's one-line monster
function schoolKitBill(o: ShopOrder): number {
  return (
    ((o.bagPrice - (o.bagPrice * o.bagDiscountPct) / 100 +
      (o.bottlePrice - (o.bottlePrice * o.bottleDiscountPct) / 100)) *
      o.quantitySets -
      (o.quantitySets >= 5 ? 100 : 0)) *
      1.18 +
    ((o.bagPrice - (o.bagPrice * o.bagDiscountPct) / 100 +
      (o.bottlePrice - (o.bottlePrice * o.bottleDiscountPct) / 100)) *
      o.quantitySets >
      2000 || o.isSchoolMember
      ? 0
      : 60)
  );
}

Be honest: how long did you stare at that? Notice the worst part — the discounted-set price is computed twice (once for the bill, once for the free-delivery check), and the two copies could silently drift apart in a future edit. That is Raju copying his bracket mistake, line for line.

The data and the function around it look simple from outside — the mess is all inside the expression:

Now we play Meena. Extract one named step at a time, tests after each.

Round 1 — name the discounted prices:

const bagPriceAfterDiscount =
  o.bagPrice - (o.bagPrice * o.bagDiscountPct) / 100;
const bottlePriceAfterDiscount =
  o.bottlePrice - (o.bottlePrice * o.bottleDiscountPct) / 100;

Round 2 — name the set price and replace both copies of the repeated expression:

const pricePerSet = bagPriceAfterDiscount + bottlePriceAfterDiscount;
const orderValue = pricePerSet * o.quantitySets;

Round 3 — name the offer, the tax, and the delivery decision. Final result:

// AFTER: Meena's rough work, as code
function schoolKitBill(o: ShopOrder): number {
  const bagPriceAfterDiscount =
    o.bagPrice - (o.bagPrice * o.bagDiscountPct) / 100;
  const bottlePriceAfterDiscount =
    o.bottlePrice - (o.bottlePrice * o.bottleDiscountPct) / 100;
  const pricePerSet = bagPriceAfterDiscount + bottlePriceAfterDiscount;
  const orderValue = pricePerSet * o.quantitySets;
 
  const bulkDiscount = o.quantitySets >= 5 ? 100 : 0;
  const taxableAmount = orderValue - bulkDiscount;
 
  const TAX_MULTIPLIER = 1.18;
  const billWithTax = taxableAmount * TAX_MULTIPLIER;
 
  const qualifiesForFreeDelivery = orderValue > 2000 || o.isSchoolMember;
  const deliveryFee = qualifiesForFreeDelivery ? 0 : 60;
 
  return billWithTax + deliveryFee;
}

Compare the two versions like Mrs. Verma comparing the two copies. The duplicate computation is gone — orderValue is computed once and used twice. The free-delivery rule, which was buried in brackets, now reads as qualifiesForFreeDelivery = orderValue > 2000 || o.isSchoolMember — an actual school policy you could read out to the shopkeeper. And if a parent disputes a bill, you can put a breakpoint on any line and watch taxableAmount or deliveryFee directly. The time saved is not theoretical:

One more observation, for your growing refactor-sense: the discount lines for bag and bottle look similar. The named variables have revealed a shared pattern — a priceAfterDiscount(price, pct) helper is begging to exist. That promotion of an explaining variable into a reusable function is exactly the stepping stone from Extract Variable to Extract Method and Replace Temp with Query.

The Same Refactoring in Python and C#

The same medicine works in every language. Python version, short and sweet:

# BEFORE
def shipping_cost(order):
    return (
        order.weight_kg * 1.5
        + (5.0 if order.region == "remote" else 0.0)
        + (0.0 if order.subtotal > 100 else order.subtotal * 0.02)
    )
 
# AFTER
def shipping_cost(order):
    base_rate = order.weight_kg * 1.5
    remote_surcharge = 5.0 if order.region == "remote" else 0.0
    handling_fee = 0.0 if order.subtotal > 100 else order.subtotal * 0.02
    return base_rate + remote_surcharge + handling_fee

Before, you could only guess what weight_kg * 1.5 meant. After, the code says it: a base rate. The return line became a sum of three honest names.

C# developers do the same with local variables — and a tangled if becomes an English sentence:

// BEFORE: squint and pray
if ((order.Total - order.Discount) * 1.18 > customer.CreditLimit
    && !customer.IsBlocked && order.Items.Count > 0)
{
    RejectOrder(order);
}
 
// AFTER: a policy you can read aloud
decimal payableAmount = (order.Total - order.Discount) * 1.18m;
bool exceedsCreditLimit = payableAmount > customer.CreditLimit;
bool isActiveCustomer = !customer.IsBlocked;
bool hasItems = order.Items.Count > 0;
 
if (exceedsCreditLimit && isActiveCustomer && hasItems)
{
    RejectOrder(order);
}

Read the after-condition aloud: "if the bill exceeds the credit limit, and the customer is active, and the order has items — reject." Three named booleans turned bracket soup into a business rule.

College corner: Do these extra temporary variables make the program slower? Almost never — and compilers are the reason. Modern compilers convert code into SSA form (static single assignment) internally, where every intermediate value already gets its own virtual name; your const temporaries simply match what the optimiser was going to do anyway. Register allocation then maps those values onto CPU registers, so a short-lived local usually never touches memory. Compilers even perform the inverse trick automatically — common subexpression elimination (CSE) finds repeated expressions (like Raju's doubled discount maths) and computes them once. So the machine plays both Meena and the eraser: it names everything internally and removes the duplicates. The performance cost of an explaining variable in compiled or JIT-compiled code is effectively zero; the readability profit is yours to keep. One genuine caution for dynamic languages: in a hot loop interpreted line by line, millions of redundant allocations can matter — but as always, measure before optimising.

IDE Support ⚙️

Editors automate this refactoring very well — they even find all duplicate occurrences of the expression and offer to replace every one.

JetBrains IDEs will highlight every other occurrence of the same expression and ask "Replace all 3 occurrences?" — say yes, and duplication vanishes in one keystroke. The inverse operation, Inline Variable, sits in the same menus (JetBrains: Ctrl+Alt+N on a variable), ready for the day a name stops adding value.

Extract or Leave It? Making the Call 🤔

Not every sub-expression deserves a name. total + tax is already a sentence; naming it grandTotal first would be furniture. Two questions settle nearly every case: how hard is the piece to read? and how many times does it appear?

Top-right is the jackpot square: hard to read and repeated — extracting kills confusion and duplication in one stroke, exactly what we did to orderValue. Bottom-right still pays: even a once-used hard expression deserves a name purely for the explaining power. Top-left earns a name as a dedupe tool. Bottom-left — clear and used once — leave it alone, and remember the inverse refactoring exists precisely for names that stopped pulling their weight.

Benefits and Risks ⚖️

When NOT to use it: if the expression is already a clear, short sentence (total + tax), adding a variable is just furniture. And here is the seesaw again, the same balance you met with Extract and Inline Method: Extract Variable's exact inverse is Inline Temp (2nd edition name: Inline Variable). When a variable's name says nothing more than its expression, fold it back in. Add names that teach; remove names that merely echo. The seesaw rests where reading is easiest. Meena writes exactly as many rough-work lines as the sum needs — never one less, never five more.

Which Smells Does It Cure?

Quick Revision Box

+--------------------------------------------------------------+
|               EXTRACT VARIABLE — QUICK REVISION              |
+--------------------------------------------------------------+
| WHAT   : Give a confusing sub-expression its own well-named  |
|          local variable. Like rough-work steps in maths.     |
| NAMES  : 1st ed: Introduce Explaining Variable               |
|          2nd ed: Extract Variable                            |
| WHEN   : Dense expressions, formula comments, tangled ifs,   |
|          undebuggable middles, repeated sub-expressions.     |
| STEPS  : 1. Check NO side effects                            |
|          2. Declare const with a MEANING-based name          |
|          3. Replace every occurrence                         |
|          4. TEST after each extraction                       |
|          5. Repeat until it reads like a sentence            |
| INVERSE: Inline Temp / Inline Variable                       |
| RULE   : Name the WHY of the value, not the HOW.             |
+--------------------------------------------------------------+

Practice Exercise 🏏

Your turn, Meena-style! This function decides a movie ticket price in one breath. Extract variables until the return line reads like a sentence. Use const, name by meaning, and pretend to run tests after each step.

function ticketPrice(show: Show, viewer: Viewer): number {
  return (
    (show.is3D ? 250 : 180) +
    (show.day === "Sat" || show.day === "Sun" ? 50 : 0) -
    (viewer.age < 12 || viewer.age >= 60 ? 40 : 0) +
    (show.seatRow <= 3 ? -30 : 0)
  );
}

Hints: four ideas are hiding here — a base price, a weekend surcharge, an age concession, and a front-row discount. Aim for a final line like return basePrice + weekendSurcharge - ageConcession + frontRowAdjustment;. Then grade yourself the Mrs. Verma way: Can each line be checked alone? Does any formula appear twice? Could a debugger watch every step? Bonus question: which of your new variables would you promote to a shared function if other parts of the app also need it? (Whisper: that is Replace Temp with Query waiting for you.) Keep practising — naming small steps clearly is one of the most valuable habits in all of programming, and it costs nothing but a moment of honest thinking.