Chapter IV · Operators & Expressions

Arithmetic Operators

Arithmetic operators do the math — addition, subtraction, multiplication, division, remainder, and exponentiation — and JavaScript follows the same order-of-operations rules you learned in school.

01 What Are Arithmetic Operators?

+ - * / % ** perform calculations on numbers. They exist because almost every useful program needs to compute something — totals, positions, percentages, timers — and a language without built-in math would force every programmer to reinvent it.

JavaScript evaluates them using standard mathematical precedence: exponentiation first, then multiplication/division/remainder, then addition/subtraction, left to right when precedence ties. Parentheses override everything, exactly like on paper.

02 Simple Example

The six arithmetic operators in action.

arithmetic.js

let sum = 10 + 5;        // 15
let difference = 10 - 5; // 5
let product = 4 * 3;     // 12
let quotient = 10 / 4;   // 2.5
let remainder = 10 % 3;  // 1  (10 divided by 3 leaves 1 left over)
let power = 2 ** 8;      // 256

% is the operator most beginners haven't seen before — it's the leftover from division, not a percentage. It's the backbone of "every 3rd item," clock arithmetic, and checking even/odd (n % 2 === 0).

03 How It Works Internally

Every number in JavaScript — whole or decimal — is stored the same way: as an IEEE 754 double-precision float, 64 bits under the hood. There's no separate integer type. This is convenient (one type handles everything) but it has a famous consequence: some decimal math doesn't land on a perfectly round result, because decimals like 0.1 can't be represented exactly in binary, the same way 1/3 can't be written exactly in decimal.

Precedence order — higher rows are evaluated before lower ones.

04 Production Example

Calculating an order total with tax — and handling the floating-point rounding correctly.

checkout.js

function calculateOrderTotal(itemPrice, quantity, taxRate) {
  const subtotal = itemPrice * quantity;
  const total = subtotal + subtotal * taxRate;
  return Math.round(total * 100) / 100; // round to the nearest cent
}

calculateOrderTotal(19.99, 3, 0.08); // 64.77

Notice the rounding step. 0.1 + 0.2 famously evaluates to 0.30000000000000004 — not a bug, just binary floating-point doing its best with a decimal it can't represent exactly. Any code that touches money should round at the boundary, never compare floats with ===.

05 Mental Model

"A calculator that never just reads left to right — it always applies the order-of-operations rules a math teacher would insist on."

Parentheses are how you tell the calculator "do this part first," overriding the default order.

06 Common Mistakes & Best Practices

Mistake: comparing floating-point totals with ===. Fix: round to a fixed number of decimals, or work in integer cents.
Mistake: forgetting % isn't "percent" — it's remainder. Fix: read it as "what's left over."
Best practice: for currency, store amounts as integer cents rather than decimal dollars to sidestep floating-point drift entirely.

07 Interview Questions

Q: Why shouldn't you compare floating-point sums with ===?

Because of binary floating-point rounding, results like 0.1 + 0.2 aren't exactly 0.3 — round explicitly or compare within a tolerance instead.

Q: What does the % operator actually compute?

The remainder left over after division, not a percentage — e.g. 10 % 3 is 1, the leftover after 3 goes into 10 three times.

Key Takeaway

Arithmetic operators follow strict precedence rules, and because JavaScript numbers are floating-point, code dealing with money or exact decimals should round explicitly rather than compare floats directly.