(upbeat music)
(keys clicking)
Okay, so we've looked at declaring variables
and using them in calculations.
We've then looked at using String interpolation
to print out more descriptive messages
with our variables.
Now we've got a couple of things to cover in this video,
and I'll start with why I've used var
for some of the variables and val for others.
And I've actually got an admission to make,
as this code is at the moment
I should've used val everywhere.
But then I wouldn't have had any familiar example code
to use for this video.
Alright, so what does this val and var mean,
and what's the difference between the two?
Well val stands for value, and var is short for variable.
Now, we can get a clue as to what the difference is
by looking at the third warning tick
that Android Studio is showing in the right margin.
So if you come down here and just hover over that,
you can see that it says "variable is never modified
"and can be declared immutable using val."
Now immutable here means that it can't be changed,
which means that once it's been given a value,
that value can't change.
Now, that may seem like an odd thing
to want to do to a variable.
After all, they're called variables,
which implies that their values will change.
And that's true, it's often necessary to assign
different values to a variable.
In that case, they'd have to be declared using var
rather than val.
Very often, though, you'll assign a value to a variable
and never change it.
Now, that might sound surprising, but it's extremely common.
You'll see examples of that when we look at functions
and classes later in this section of the course,
but as an example of this,
look at the declaration here on line 5 for the tim variable.
Now I could probably imagine an extreme set of circumstances
that would result in my changing my name
and going on the run and going into hiding.
It's possible, perhaps, but I think I can safely guarantee
that my name will remain Tim Buchalka,
I won't change in the time I'm recording these videos,
at least, if ever.
So the point is that there's very little point
storing my name in a var variable.
Once it's stored, it's not going to change.
Alright, so that's fair enough,
but what's the big deal?
After all, we just have to avoid changing it,
and everything's fine, right?
Now this bit's going to be a little bit contrived,
and we haven't got a lot of code here,
so it's gonna be obvious where I'm about to go wrong.
But remember that a real programme will have hundreds
or thousands of lines of codes
split over loads of different files and classes.
So what I'm gonna do here is start by adding
another variable, Jim,
and I'm gonna do that above tim on line 5.
So V-A-R, jim, J-I-M, colon, String.
Alright, so now that we've done that,
we're gonna go down to the code
right down to the bottom here,
we're gonna give jim a value.
So right after the last println
we're going to put tim equals James T Kirk.
Now when I run the programme,
you can see that it says "My name is James T Kirk,"
so I'm no longer Tim Buchalka.
I've become the captain of the enterprise instead.
The rest I've said, this is a bit contrived,
but errors like this are surprisingly easy to make
when you're dealing with hundred of variables
and thousands of lines of programming code.
Now, we can prevent bugs like that from creeping in
by declaring variables as val
when we don't expect them to change.
So I want to go up here into line 6
and change the var to val.
And scroll down and have a look,
the code now would no longer compile a run.
We're actually getting a warning here,
an error rather saying val cannot be reassigned.
So it's an error showing that
when I incorrectly try to assign
a new value to tim at the end of the code.
So the Kotlin compiler is catching the bug for us
and not allowing the code to compile.
So as a general rule, always use val
unless you're sure that you're going to change
the value of a variable.
Now if you find that you do need
to assign a new value to a val,
you can always go back and make it
a var instead at that point.
Alright, so I'm going to correct that rogue line
so that we assign to jim instead of tim.
And let's also print something.
We'll actually replace line 32.
What I'll do is come down here
and on line 33, we'll change that to put
"jim is dollar jim."
Okay, we'll run that code.
Quickly now, showing "My name is Tim Buchalka"
and the jim variable is correctly assigned
to the value of James T Kirk.
Alright, so Android Studio is helping to identify
variables that don't change,
and all uses of var are actually highlighted.
We can actually start by clicking on var on line 5,
over here, and we get the tool tip
suggesting it can be a val as you can see here.
"Variable is never modified
and can be declared immutable using val."
But even better, though, if I double click it,
we get this little light bulb up here
in the left-hand side,
and we can come down here, we can click on
make variable immutable, and that changes that,
as you can see, to a val now.
And obviously, that warning then disappears.
Right, so let's do the same for the other vars.
So I come down here, we can declare that,
by double clicking it, make variable immutable.
Same for timsMonthlySalary, double click the var,
change that to make variable immutable.
We can come down here to fruit, double click,
you can also make that variable immutable as you can see.
And that's all the vars now converted to val.
In this case we can do that
because we're only assigning a value to them once.
Alright, so let's now have a look at some of the warnings
that are still showing in the right hand margin.
Now the first one, if you look carefully,
it looks like it's changed colour slightly.
It's now a suggestion where as before
it was showing us a warning.
Now suggestions aren't as important as warnings,
but your code will be more readable
if you take note of them.
So this one here is saying "Can be joined with assignment."
And by the way, clicking on one of these warnings
will take you to the line of code that's applicable
for that particular warning.
Now we can come over here, double click it again,
and we can come down and select the light bulb,
and we'll click on "Join declaration and assignment."
And you can see that that's pretty impressive.
It's pulled the assignment of the jim variable
from the end of the code and added it to our declaration.
So jim's now initialised at the point where it's declared,
and that's good programming practise.
So I can do the same for tim on the next line,
just by double clicking on it and selecting the light bulb,
clicking on "Join declaration and assignment."
Alright, so let's look at some of the other warnings now.
"Explicit given type is redundant,"
and they're actually all the same
at this point forward, now.
All these warnings are all the same now,
"Explicit given type is redundant here."
Now, I said that you have to tell Kotlin
what type of value each variable is gonna be given,
but that's not strictly true.
Now, every variable has to have a type,
and once you've made it a String, say,
you can't go assigning a number to it.
But we don't have to explicitly tell Kotlin the type.
Kotlin's very clever and can work out
what the type should be most of the time.
Now the first warning is here on line 5,
I click on over here where we assign
a String the the variable jim.
Now if we're making jim equal to the String,
then double quotes and whatever the name of the String is,
then jim's obviously a string.
So in other words, if the value
is surrounded by double quotes,
quite clearly, that's a string.
And that's what the warning's saying here.
Kotlin can work out that jim is of type String,
so telling it that it's a string is redundant.
And again, what we can do here is just to double click,
click on the light bulb, and we can click on
"Remove explicit type specification."
And now that I've done that you can see it just says
val jim equal double quotes James T Kirk
and then another double quote.
So result, I think you'd agree that line 5
now is a lot easier to read than line 6,
and we've removed that redundant type
and we've actually removed that warning as well.
Now when the code's compiled, the Kotlan compiler
will infer the type that jim should be.
Now, you'll come across the term "type inference"
in the documentation, and that's what it means.
Kotlan can work out what type something is.
Right, so I'm gonna use the light bulb now
to actually remove the remaining redundant type specifiers.
So I'm gonna start with the next line,
I'm gonna double click on that.
I'm gonna change tim, remove explicit type specification.
And the next one, timsWeeklySalary.
Gonna remove explicit type specification.
Next one, timsMonthlySalary,
remove explicit type specification.
Now that can also be inferred, but there's no warning,
but the light bulb did appear when I clicked on
the variable while type,
and also appeared by the white,
and you can, by double clicking on the extra variable top
that'll produce a light bulb
or make the light bulb appear as well.
I can click on "Remove explicit type specification
for that as well.
And continuing on down here, I can double click on apples.
Remove explicit type.
Oranges, remove explicit type.
Fruit, remove explicit type.
Weeks, remove explicit type.
Years, remove explicit type.
Okay, so that's basically all the changes there.
Now that's actually removed all the warnings,
and our code's more readable without that clutter.
Notice now that I've done that,
in the the top right-hand corner here there's a green tick.
Now that's telling us that there's no other warnings.
We've got these other things here,
which aren't warnings as such.
So this is what you should be aiming for in your code.
A green tick to indicate that
there's no outstanding warnings or suggestions
and obviously, no errors.
Now it's always worth checking out these
warnings and suggestions, as they'll often help you
to write more idiomatic Kotlin code.
You can ignore them, but paying attention to them
and acting on them can improve your code.
Alright, so I'm going to stop this video here.
In the next one, we're going to look at
how our code can make decisions.
See you in the next video.