If you're coming from Java, C#, or JavaScript, you're probably used to thinking of control flow as a set of instructions—a sequence of "do this, then do that." In those languages, an if block is a statement; it performs an action but doesn't "become" anything. When I first started with Scala, I spent the first few weeks writing code that looked exactly like Java, and it was a waste of the language's best features.

The mutable "var" trap

Let's look at a common scenario: calculating the price of a subscription based on a user's tier. In a statement-based mindset, you'd probably declare a mutable variable and then update it inside your logic. It looks something like this:

var price: Double = 0.0
if (tier == "Pro") {
  price = 29.99
} else if (tier == "Basic") {
  price = 9.99
} else {
  price = 0.0
}
// Now 'price' is ready to be used

This works, but it's brittle. I've seen this pattern lead to bugs in huge codebases because someone accidentally modifies price somewhere between the declaration and the final usage. You're forced to use var, which means you've just introduced mutable state into your function. Every time I see a var used just to get a value out of an if block, I feel a slight twitch in my eye. It's just unnecessary risk.

Leveraging the return value

In Scala, if is an expression, not a statement. This means it returns a value. You don't need to update a variable; you can just assign the result of the entire if/else block to a val. This is a fundamental shift in how you should approach your logic.

val price = if (tier == "Pro") {
  29.99
} else if (tier == "Basic") {
  9.99
} else {
  0.0
}

Notice that I swapped var for val. The value is determined at the moment of assignment and can never change. It's cleaner, it's thread-safe, and it tells anyone reading your code: "This value is decided once and stays this way." I personally find this makes debugging significantly easier because you don't have to scan the rest of the method to see if the price was tweaked by some other conditional block further down.

When if becomes too noisy

While if as an expression is great, it starts to get clunky when you have more than two or three conditions. That's where pattern matching comes in. Just like if, a match block is an expression. It doesn't just branch the code; it evaluates to a value.

Compare the if/else chain to this:

val price = tier match {
  case "Pro"       => 29.99
  case "Basic"     => 9.99
  case "Enterprise" => 99.99
  case _           => 0.0 // The 'wildcard' handles everything else
}

The logic is identical, but the intent is much clearer. We've moved from "checking conditions" to "mapping inputs to outputs." This is the "Scala way." Instead of telling the computer how to step through the logic, you're describing what the result should be based on the input. Whenever you find yourself writing an if/else chain that assigns a value, stop and ask yourself if a match expression would be more readable. Usually, the answer is yes.

📋 Practical Task

Build a Tiered Shipping Cost Calculator

You need to implement a function that determines the shipping cost for a package. Instead of using mutable variables and statements, implement this using a match expression to return a value directly to a val.

The Requirements:

• If the destination is "Local", the cost is 5.00.
• If the destination is "National", the cost is 15.00.
• If the destination is "International", the cost is 50.00.
• For any other destination, the cost should be 0.00 (representing an invalid destination).

Write a small program where you define a variable destination and use a match expression to assign the correct cost to a val shippingCost. Print the final cost to the console.