Transcript from the "Variable Declarations" Lesson
>> Mike North: So let's look at separating variable declarations and initializations. So, often, we need to do this. One place I can think of that I do this is if I have a variable that takes on a different value based on some conditions. Maybe I have a case switch with five or six case clauses, and I wanna set the value of something based on which of those clauses I fall into.
[00:00:26] I'll probably declare that variable outside of the switch statement, and then assign it in each of the clauses. So you end up with something like this, but we run into something that looks a little bit troubling here. We initialize it to 41 or reassign it to 41 cuz it has no initializer.
[00:00:46] And then it looks like we can use a string as well. And this gives us a clue as to what's going on here, z takes on a type of any. It's basically a wildcard. Well, type systems, in general, call this a top type. Top types can take any value.
[00:01:39] You just wanna make sure that wherever you have it, you actually want to allow absolutely anything.
>> Mike North: So we could improve the situation if we wanted to by, in our variable declaration, specifying a type. And this is called a type annotation. We're sort of attaching a little extra piece of information to the variable that says, look, you don't have an initializer, but I'm telling you number is what you're designed to hold.
[00:02:12] And now we get our desirable type error if we try to put a string into this variable. So this is something you gotta watch out for, right? If you have declarations where you don't initialize the variable, you're gonna wanna specify what type this is designed to hold. Yes?
>> Speaker 2: So in the official docs of TypesScript, they generally do do that type declaration, even if you're initializing the variable with a value. Is it recommended to do it that way or no, or does it now matter?
>> Mike North: That's a great question. I would say it's recommended to do that way if you are writing docs because you are being very descriptive in documentation.
[00:02:58] And what's more, I'm sure the TypeScript team would love to have the ability to show tool tips in their docs where you could hover over things and see what they are, right? So like in this example up here, describing that this is of type hello world, like to write that out on text, you might be verbose in doing so for descriptive purposes.
[00:03:22] But because we have an editor here, we don't have to do that. I err on the side of providing type information in a few specific places. Variables with initializers, not one of those places because TypeScript can always infer at that location. Now, I'll be very clear to point out spots where I always put type information as a way of kind of setting deliberate boundaries around pieces of code.
[00:03:52] Basically, what I'm trying to do when I provide type information is provide an explicit contract between two things, and keep myself honest on both sides of that contract. But here, it would sort of just be extra stuff. But I would write my docs in the same way to be clear.