Mutable variables (var) and type inference

1. Mutable variables (var) and type inference

So, that was immutable variables, or vals. Now, let's do their mutable counterpart: vars.

2. Scala has two kinds of variables

vars are mutable, which means they CAN be reassigned. In Twenty-One, an ace is like a var, as it can be worth 1 or 11 points depending on the player's choice. We write var, the variable name (aceSpades), the type (Int), then equals 1. vars are similar to non-final variables in Java if you're familiar.

3. Reassigning a val produces an error

You saw that since fourHearts is a val, the Scala interpreter yelled at us when we tried to reassign it.

4. Reassigning a var works

Since aceSpades is a var, reassigning it the point value of 11 works just fine.

5. Pros and cons of immutability

At first think, it seems like having a variable that you CAN'T change is a terrible idea and that we should always use vars over vals. But, in Scala, we actually prefer immutable variables (vals, that is) where possible. Here's a few reasons why. First, your data won't be changed accidentally, by an error in your program's logic for example. Preferring immutability is a form of defensive coding. Second, your code is easier to reason about since you don't have to mentally juggle all of the places where your data can change. Third, immutability means you'll have to write fewer unit tests to make sure your program works as expected. The main drawback of immutability is the extra memory generated by copying objects. Since vals can't be reassigned, to change them you'll need to create a new object. Your programs will be a little larger. Fortunately, unless you are working with massive data structures and copying them thousands of times a second, the pros often outweigh the cons.

6. Scala nudges us towards immutability

As you'll experience throughout your Scala journey on DataCamp, Scala nudges use towards immutability. BECAUSE we are forced to copy our objects each time we want to make a change, we become much more conscious of HOW and WHEN we change our program's state. With this philosophy, we receive fewer possible states within our programs, fewer defects, and codebases that are easier to maintain.

7. Type inference is powerful

We've defined vals, like fourHearts, and vars, like aceSpades. Using a powerful feature of Scala called type inference, we can make this code even more concise. All we need to do is drop the colon then the type (Int, in this case). Scala can infer that fourHearts is an Int because it knows whole numbers like 4 are typically meant to be integers. Type inference not only applies to variables, but also collections, functions, and more, with the rule of thumb being programmers can omit almost all type information that's considered annoying. Type inference saves keystrokes and characters, which is a big deal in massive codebases. You'll experience type inference more in this course later.

8. Semicolons

There is something else that contributes to Scala's conciseness. You may have noticed there are no semicolons at the end of these statements.

9. Semicolons

There could be, but Scala tries very hard to let us skip semicolons wherever possible. And

10. Semicolons

most Scala programmers do, so we'll do that too.

11. Let's practice!

Now, you can concisely define mutable variables and understand why Scala prefers us to use their immutable counterpart. Let's practice.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.