Scala Tutorial: Mutable variables (var) and type inference

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

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.

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

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

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.

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.

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.

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

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

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

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

#DataCamp #ScalaTutorial #Scala #Mutable #variables #typeinference