Hello everyone and welcome to the eighth episode
of the PowerShell video series, wow that’s a lot of episodes. Yay! So, we are nearing
the end. In this episode, we’re going to take a look at taking our scripts even further,
using things known as “if statements”. As well as covering a few other bits and pieces
along the way. Before we get back into scripting, however,
I’d just like to quickly go over something we’ve been using a lot in our time with
PowerShell, but haven’t really taken a closer look at yet, and that’s operators. What
is an operator? Well, it’s this thing here. Remember how inside “Where” we can write
“-eq” and such to compare two things? That -eq there is what we call an operator.
And remember how you can add numbers, or strings or whatever, together, like this? Well, this
+ is an operator. All an operator is, is essentially a thing
built into the language that allows you to perform a specific action of some kind on
some objects. For example, the “-eq” operator checks if the object on the left and the object
on the right are equal or not, and if they are it gives “true” and if they aren’t,
it gives “false”. This “-eq” is a feature available in the language to compare
two objects. Not all operators come in the same form as
“-eq” and “+”, where you have one thing on the left and one thing on the right.
Another operator we’ve been using a lot is casting. Those square brackets with text
in the middle make up a casting operator. Or another example of an operator we’ve
been using is dot. This operator lets us access a smaller member and two colons lets us access
static members under a type, all of these things are operators.
And all of these operators can be used anywhere we want. As you probably remember from a few
episodes ago, you see this “-eq” operator here? We could put this anywhere; I could
literally just write out on its own. It doesn’t have to be in a Where, operators are just
their own thing you can do whenever, they’re technically completely unrelated to “Where”
or anything like that. So, what are all the operators? Well, there
are a lot for all kinds of different things, and I’m not going to go through all of them.
There’s no need to anyway, you’ll just discover new ones as you go along using PowerShell
anyway, so it doesn’t even matter. There is a list of all of them in the description
if you really want to look through them all, but I wouldn’t recommend it, just learn
them naturally as you go along using PowerShell. Let’s start with some ones we already know.
The comparison operators, these are designed to let us compare two objects in some way
and get a Boolean back saying whether the comparison matched or not. The simplest comparison
operator is “-eq”, which we’ve used a lot throughout the series. This checks if
the thing on the left and the thing on the right are exactly the same, not slightly the
same, not the same except the stars, exactly the same. And there’s also “-ne”. This
stands for not equal to and it’s essentially the opposite to “-eq”. If the two things
are not the same it will give “true”, and if they are the same, it will give “false”,
so it’s the other way around from “-eq”. Now, there is one thing important thing you
need to keep in mind about these two. For most things these two will work just fine.
For example, I can compare integers with “-eq”, and this will compare the two correctly, and
I can compare strings, and this will compare the two correctly and so on. But the reason
why it compares the strings and integers correctly is not by magic. String objects and integer
objects have certain methods on them that PowerShell will call to do the comparison.
So, if I go to compare two strings, the way PowerShell knows if these two are the same
is by calling a comparing method all string objects have on them, that goes in and does
all the necessary stuff with the length and the character data and all of that to compare
the two. And most types you’re going to be comparing
are going to have said methods on them, so they do compare correctly. However, and it
is quite rare, but it may happen that you could encounter a type of object that does
not have these comparison methods on them. And when you have an object like that, trying
to do “-eq” on it may not work as you expect. For example, let’s quickly make
our own object, just our own custom object with our own properties. To do that, we’re
going to make a hash table, put in some items with what properties we want, and then cast
it over to “PSCustomObject”. So, there’s one object there with a property called “P”
and the value of “5” in it. And let’s make a second object that also has a property
called “P” and the value of “5” in it.
Now, these objects we just made, have no methods on them. Well, they have a few methods on
them that every type has, like “GetType” and stuff, but beyond the basic stuff everything
has, they don’t have any extra methods on them. And that includes the comparison method
“-eq” runs, it’s just not there on the object. So, what does “-eq” do when we
compare two objects that don’t have a comparison method on them? Well, let’s try comparing
these two objects we made and see what happens. So, we’re going to compare the first object
here and the second object, and you’ll see it gave me false. Which is interesting because
both of these objects have exactly the same properties with exactly the same values in
them. They both look identical, and yet “-eq” is saying they’re not.
The reason this is happening is when a type doesn’t provide a proper comparison method,
what “-eq” does is it doesn’t look at anything inside the object. It doesn’t look
at the properties, or the data in it, all “-eq” looks at is the object itself. And
what it does is it checks whether the thing on the left and the thing on the right are
exactly the same object or not. These two are not exactly the same object. They both
have the same stuff in them, yes. They both represent the same thing. But that doesn’t
mean they’re the same object, these are two different objects, we made them separately.
So, “-eq” gives “false”. Now, if we set “b” to “a”, then it’s
a different story. What we’ve now done is taken the object in “a”, the exact same
object we have in “a”, and we’ve put it into “b” as well. So now, both variables
contain exactly the same object, and if we run “-eq” now. You can see it’s giving
“true”. It’s quite rare you’re going to encounter
a type where this happens. But if you ever see “-eq” giving “false” when two
objects both represent the same thing, that’s because the objects aren’t providing a way
for PowerShell to compare them properly. To get around this, what I could do is just compare
the property “P” instead. So instead of trying to compare whole objects, I’ll just
compare property “P” of the first to what’s in property “P” of the second one, and
that will in this case check if they’re “the same” as we’d call it.
There is just one more thing I’d like to say about “-eq”. Now, I know I said it
compares exactly, but there is an exception for that, and that is with strings. When you
compare two strings with “-eq”, “-eq” will ignore the capitals. So, if I ask PowerShell
whether lower-case “a” equals capital “A”, it will give me “True”, to say
that, yes, they do match, because it ignores casing. It’s not case sensitive. If you
want case-sensitive comparison, where it does care about the case, then you can use “-ceq”,
where the “c” stands for “case-sensitive”. Anyway, yeah, that’s “-eq”. There are
a few more comparison operators too. We also have “-gt” and “-lt”, which stand
for greater than or less than. And they check if the thing on the left is bigger or smaller
than the thing on the right. So, if I do “10 -gt 5”, that’s asking if 10 is greater
than 5, which it is, so that will give true. And there’s also less than for asking if
the left is smaller than the right. And these two are exact, if I ask if 10 is
less than 10, it will give “false”, because 10 is not less than 10. However, if you want
to ask whether the left is less than or equal to the right, then we can write “-le”.
And this gives “true” if the thing on the left is less than or is equal to the right
or is just the same as the thing on the right. And there’s also “-ge” for greater than
or equal to. There are also some pattern-based operators.
These let us compare strings in some very nice ways. The first one is “-like”, and
we have seen this before, this operator checks if the thing on the left matches the thing
on the right, but unlike “-eq” which just does an exact comparison (except casing),
the thing on the right can have wildcards in it. There are a few different wildcards
you can use, and you can put them in the thing on the right and they essentially allow you
leave blanks in your comparison. So, if I write this, this is asking whether
variable “s” has a string in it with “a”, followed by any characters, I don’t care
what characters, and then a “b” after that. We used this earlier in the series on
the command “Get-Command”, which recognises wildcards in its first parameter. So, if I
do “Get-*”. This is saying “get me a command that starts with “Get-“, and then
whatever characters, I don’t care what”. And there’s a few more wildcards like “?” and
such that behave a little differently, but I won’t get into that in this series, the
documentation is in the description if you want to read about them.
There’s also a “-match” which is very similar to this but the thing on the right
uses something called regex, regular expressions. Regex is a very common, standard way of comparing
text in really complex ways and it can get super complicated, it’s very powerful. I
won’t get into Regex in this series, it basically needs its own dedicated series,
and there are hundreds of places explaining it, it lets you do very complex text comparison.
There’s also a “-notlike” and “-notmatch” which are opposites, like how “-ne” is
the opposite to “-eq”. Alright, cool! Let’s wrap up operators quickly
now so we can move onto some scripting. There is just one more set of operators I want to
cover now, and that is the Boolean operators. So, as you’ll remember, all of these comparison
operators give back Booleans, right? Well, there are some operators we can apply to Booleans
that do certain things with them and manipulating the Booleans we get from these operators can
be very useful for us to do more complex conditions with “and” and stuff. Let me show you.
The first operator is “!”. And you write like this, you write “!”, and then follow
it by a Boolean. This operator inverts the Boolean we give it. Meaning true becomes false
and false becomes true. So, if I have a variable with “true” in it, like, well I guess
the variable “true”, and I put an “!” before it, it will give back “False”, it flipped
the Boolean after it around. Just like a lot of the other operators, it doesn’t affect
the variable, it gives back a new flipped around Boolean.
There’s also an operator called “-and”. And this is quite useful. This operator takes
in a Boolean on the left, and a Boolean on the right. And only when the left and the
right are “true” does it give back “true” (you can see where it got its name), in all
other cases, it gives back “false”. And there’s also an operator called “-or”,
and this gives back “true” if either the left or the right is “true”. It gives
“true” if at least one of the two sides are true.
So, if the left is true but the right is false, it gives “true”, because one of them is
“true”. If the right is true, but not the left, same thing. If both of them are
“true”, that’s still “true”, at least one of them are true. But, if both of
them are “false”, that gives “false”, because not one of them are “true”.
Now, the place we use these two most commonly is in conditions. Let’s say I want to make
a “Where” that says “where” the CPU time is greater than 10 and the “Name”
matches this wildcard string. Every item has to match both of these things, both of these
things need to give “true” for an item to be selected. Well, I can do that using
the operator “-and”. What we’re going to do is on the left of
the -and we’re going to run “-gt” to check if the CPU time is greater than 10.
And then on the right of it we’re going to run “-like” to check if the “Name”
matches that wildcard string. Now, let’s say I have this object, and it
goes into the “Where” to decide whether we it be included. Let’s see what this does.
So, first it does this: Is the CPU time greater than 10? Yes, it is, so that side is going
to have “true” on it, because the “-gt” is going to give “true” there. Alright,
cool. Now, let’s move over to the second side, does the Name follow this pattern? Yes,
it does. So, both sides of the “-and” have “true” in them. So, the “-and”
sees that both sides gave “true” and gives “true” back because of that. The “Where”
then sees that “true” and the object is included.
But let’s say we changed our object to look like this instead. Now, the name doesn’t
match the pattern, so let’s see what happens now. So, the left side runs, and it checks
to see if the CPU is greater than 10. It is, so it gives “true”. Then we go to the
other side, it checks if the name on the object matches the pattern, it doesn’t. The name
does not match the pattern we got there, so this side gives “false”. And because they’re
not both true, the “-and” gives false. So, hopefully you can see how this “-and”
here is allowing us to say where one thing and another thing. And only when both things
on each side of the “-and” give “true” will the “-and” give “true” and the
“Where” will accept the item. Basically, you can use “-and” to say “and” in
your conditions, that’s basically what it allows you to do. And you can also use “-or”.
If you use or, the object needs to either have a CPU greater than 10 or have a name
matching this pattern to be accepted, either side being true will be enough to make it
give “true” and have the “Where” or whatever accept the item.
Now, in both of these examples you’ll notice I wrapped the “-gt” and the “-like”
in brackets. And the reason why I did this is to make sure those run first, and their
result definitely gets treated as this single block, this single value, that’s then handed
to “-and”. However, if we’re being really exact, when
it comes to “-and” and “-or” you can go without brackets. But why? How does it
not get confused and not see it like this or something? What makes it see it like what
we had before, and not something weird like this.
Well, it all comes down to a concept known as “operator precedence”. Certain operators
are more important than others. And the more important ones always run first. So, “-gt”
is has more importance than “-and”, which causes it to always run first. Same goes for
“-like”, and that causes the two to behave just like they were wrapped in brackets when
put alongside “-and”. You’re actually very familiar with operator
precedence already from maths. Remember the order of operations? BODMAS? Or however you
learnt it. Well, that’s operator precedence happening right there, certain things, like
“*” are more important than “+” and will always run first. So if I do “3 + 4
* 5” in PowerShell, PowerShell won’t see it like this, it will see it like this, because
the “*” operator is given more precedence than “+”, the “*” will always happen
first when put alongside a “+”, that’s just how the operators are treated.
And in our case here “-gt” and “-like” have more precedence than “-and”, therefore
causing them to run first, and then have their results used in the “-and”. That’s by
design, they specifically ordered their importance like that to try and make using “-and”
as easy as possible without needing the brackets. However, I personally like having the brackets
there, it just makes it really clear to the reader exactly what’s happening. I don’t
even know the operator precedence in PowerShell very well, I just prefer wrapping things in
brackets to make it as clear as possible what should be happening first instead of trying
to memorize what order operators take importance, it’s just clearer to see like this in my
opinion. In the description you’ll find a list of all the operators in order of operations
though if you’d like to take a look at it. There’s just one more thing I’d like to
mention about operators before we move on. A lot of the operators in PowerShell behave
specially when they have a collection on the left of them. When you put a collection on
the left of an operator, what PowerShell will usually do is apply that operator to all the
items in the collection. For example, if I make an array with these three strings and
I write “-like” like this. It’s going to do this “-like” on each item, and it
will give back all the items that did match. And most operators will do this.
Alright, that’s enough on operators, let’s get back to scripting. There is a reason I
covered operators by the way, and we’ll get to that soon. So, here we are in Visual
Studio Code, and this is the script we wrote in the last episode. Now I’d just like to
quickly introduce you to a very neat little feature known as “comments”, which is
something that’s going to help us out a little bit when making scripts in the future.
A comment is a thing we can put in the script that PowerShell completely ignores. PowerShell
pays absolutely no attention to it. And we use one to put a message in the script,
just to guide anyone reading the script’s code if there’s anything that needs explaining.
To make a comment you just write a hashtag and that will make the rest of the line a
comment. So, if I do this, I can now put absolutely
whatever I want after the hashtag, and PowerShell won’t pay any attention to it, it’s just
there as a message to help someone reading the script out. So, I could put a message
in here saying add a LineCount property to each file. So now, when someone comes in here
to read this script and try and understand what it’s doing, they’ve got this nice
comment here letting them know what the next bit is doing. So, yeah, a comment is just
a message you can put in the script to help out someone reading it. You can also put them
comments at the end of lines like this if you want, and PowerShell will ignore everything
after the hashtag. Now, one thing I said I’d mention in the
last episode is this “Visual Studio Code” app we’re using. Visual Studio Code is a
text editor geared towards programming, and the cool thing is it has support for PowerShell
scripts. If you go onto the Visual Studio Code website, and install it, you can then
open it up and drag your PowerShell script into it. And then down here in the corner
it will give you an option to Install the “PowerShell” extension, which gives you
all the fancy colouring and suggestions and all of that. And when you install it, you
now have the same experience I’m seeing here.
It’s awesome, because I just write something, and it pops up with suggestions of what I
could want. So, let’s say I want the command “Import-Csv”, there it is, I’ll choose
that, it auto fills it in, and it gives me lots of tooltips too. So, you’ll notice
right here it’s actually telling me all the parameters on the command, and what type
they take in all of that, which is super cool. And I can put my mouse over things, and it
talks about them. It’s great. Now, one thing I want to draw your attention
to are these yellow lines. This script has quite a few of them, and in the last episode
I just ignored them for the time being, but if you get one, you shouldn’t ignore it.
This yellow underline is what’s known as a warning, it’s warning me about something
right here. Now, when you get a warning about a bit of code, you technically can ignore
it. The PowerShell is still valid, this is all valid, it will run and all of that. But
the warning is usually telling you about something you could be doing better, or it can sometimes
catch things you probably didn’t mean to do.
For example, if I make a variable, and set it to, I don’t know “5”. If I don’t
use that variable anywhere. I’ll get a warning telling me that I’m making this variable
and then not doing anything with it. It’s letting me know that this line here is pointless,
I’m just making the variable for no reason. It will still run of course, but it’s letting
me know that doing this pointless. So, what’s this warning about? Well, if
I put my mouse over the line, it will tell me what’s it’s warning me about here.
And it’s telling me that “%” is an alias and it’s not recommended to use aliases
in scripts. And that’s actually true. In general, aliases are designed to be used in
the console here, which is what we’ve been doing most of the time.
But in scripts, it’s generally not good practice to use them. You can obviously still
do it, it will still work, it’s just not recommended, and that’s what warnings are
all about. So, I’ll replace this with “ForEach-Object”, which is the full command name. Cool. No more
warning. And there are also errors, which are red underlines.
You’ll get an error when PowerShell can’t understand your script. For example, let’s
say I make a hashtable and I put… This in here. Well, this isn’t valid, I’m only
giving the key, where’s the value to go with the key? and if we look at the error,
we can see it says that it’s expecting to see an “=” in there to provide the value
too, that’s how you make hash tables, not this. So that’s an error, it’s wrong and
it can’t understand it. One thing you do need to be aware of is errors
you see in here only tell you PowerShell can’t understand your script. It’s perfectly possible
to have a script it understands just fine but that crashes or doesn’t do what you
want. So just because there are no errors doesn’t mean your script will definitely
work and that it definitely won’t give an error when it tries to actually do the actions
you describe. Anyway, with that said, I’d like to introduce
something new, and this is the next big topic for this. We’ve learnt a little bit about
scripting, but to be able to really take our scripts to next level, we need to bring in
something called the “if” statement. This is something built into the PowerShell language
that lets you run a block of code only if a condition is true.
For example, let’s say we want to write a very simple script that goes like this.
It asks the user whether they like ABMedia. If they enter “Yes”, then it prints out
“OK, that’s good, you’re sane”, and if they don’t say “Yes” and they just
say something else, then it says, “I- I don’t even know who I’m talking to anymore”.
So, a pretty simple script, right? But how can we do this? Where it changes what it does
based on a given thing. How can we do that? Well, we can use an “if” statement to
decide what to run based on a condition. What we’re going to do is first print out
to the user “Do you like ABMedia”. Then, we’re going to use “Read-Host” to get
them to enter in an answer. And we’re then going to use an if statement to say if what
they entered was “Yes” do this, otherwise do this.
The way you make an “if” statement is by writing “if”, then brackets, and in
these brackets, you put in the condition. And after that you put in curly braces like
so, and everything you put into these curly braces will only run if the condition is true.
Once the “if” has run everything in the curly braces, it will go on to run what’s
after it too, it doesn’t stop there. So, this is where we need to decide. If the
“answer” is “Yes”, we’re going to print out the sane message. If the answer
is not yes, we’ll print out the insane message. So, what I’m going to write is “if”,
and then brackets. And inside these brackets we put the condition. If what? If the answer
equals “Yes”. And then we put in curly braces. And perfect, that’s an “if”
statement right there. If the answer equals “Yes” then everything we put inside these
curly braces is going to run. So, we’ll say that if they entered “yes”, they are
sane. Now, notice how I’m putting spaces before
this, I briefly mentioned this in the last episode but didn’t actually explain exactly
what this is. This is what’s known as indentation, and it’s something you do in every single
programming language. These spaces here mean nothing. PowerShell doesn’t pay any attention
to them, they don’t affect how PowerShell works or anything like that, I could go without
them if I wanted. But what the spaces are there for is for clarity.
Every single time you enter inside a block, so most of that time that’s when you go
inside curly braces, you push everything inside that block forward by spaces. You indent everything
in the block. And everytime you leave a block, so that’s the closing curly brace, you unindent
again. The reason why we use indentation is it makes
it very clear what is inside what. Now, I know it might not be obvious to you right
now, but if you put “if” statements within “if” statements (which you can do, there’s
nothing stopping you from doing that), and then you start putting foreachs in there,
and all these different things that have stuff inside them, if you pushed everything together
so it was all in line, it start to become extremely difficult to figure what’s inside
what, it would just become a complete unreadable mess.
So, what we do, is when you enter inside something, typically with curly braces, you push everything
inside that thing forward one more than it was before. You may not see the benefits now,
but trust me, do it and when you start writing much, much more complex scripts, you will
see huge improvements to its readability. Alright, great! So, if we run it now, it’s
going to ask us the question, and if I enter “yes”, it will say that, yes, I am sane.
But if I run it again and don’t enter “yes”, this condition here will be “false”, the
message we entered will not be “yes”. So, what’s going to happen is it’s going
to skip straight over the curly braces, it’s going to skip straight to here, nothing in
the curly braces will run. And since that’s the end of the script, it will end. So, right
now, if I enter something that’s not “yes”, it will just end without saying something.
Obviously, we want it to say something in that situation too, so how can we do that?
Hmm… How about we add a second “if”. If what they entered was not “yes”, then
we’ll print the insane message. So, after or before this if, we’re going
to say if their input was not equal to “yes”. And if that’s the case, then we’ll print
the insane message. So now, if the message was “yes”, this if statement triggers,
it will print the message, and then it will carry on. And this if statement is false,
so it’s not going to run any of this or any of that.
Or, if the message was “no”, this if statement will not trigger, because it’s not equal
it’ll just go through without doing the thing in the curly braces. But this if statement
will trigger because they’re not equal, so it will print out the message. So, if we
run this script, we can see it works. Now, this works, but there is a much better
way to do this. Instead of repeating the exact same “if” again, wouldn’t be nice if
instead we could say “otherwise” here. So, if this condition, do this, otherwise,
do this. Wouldn’t it be nice if we could just say that?
Well, we can! Introducing “else”! If you put an “else” straight after the curly
braces of an “if” statement, like this, it basically becomes an “otherwise” to
the if statement before it. So, what PowerShell sees here is if the text equals “yes”,
run this code, and then hop down here. But if the text doesn’t equal “yes”, run
this here, and then hop down to here. And that’s it, there’s our script done,
this is how you’d write it. Also, just a quick tip, there is actually a “Prompt”
parameter on the “Read-Host” command, and we can use that instead of “Write-Output”,
just thought that was worth mentioning :P Alright, so that’s a script done. How about
we use this “if” to do something more complex, then. What we’re going to do is
make a grade calculator. What you do is you enter in a percentage and PowerShell gives
back a letter grade from F to A based on that percentage. If the percentage is above 90%,
it will say back “You got A” (yes, very high expectations I know), if it’s above
80%, it will give you “You got B”, and so on.
So, how can we do this? Well, what we’re going to do is use a bunch of “if”s checking
our input. If it’s above 90, we’re going to print out “You got A”. If it’s above
80, we’re going to print out “You got B”, and so on.
So, let’s do that. First, we’ll ask the user for their percentage, and we’ll put
that into a variable, and we’ll also cast that into an integer, since it is, after all,
a number. And now, we need to do a bunch of “if”s to print out a different message.
If you’d like, you can pause the video right now and try it out if you want, feel free
to do that, but I’m going to take it through with you now.
Alright, so, let’s start with how you might think you’d do it. This is not necessarily
the right way to do it, just how you may think you’d do it. So, what we’re going to do
is make one “if” statement for each grade. One if statement checks if the grade is greater
than 90, and prints “A” if so, another checks if the grade is greater than 80 and
prints “A” if so, and so on. So, let’s do that. Let’s just start with Grade A I
guess, why not. So, if the percentage is above (or equal to,
actually, let’s do or equal to) 90%, it’s going to say, “You got Grade A”.
Great. Onto the next “if” statement. This is for the next grade down, the “B” grade.
If the user got above or equal to 80%, we’re going to print “You got B”.
Now that we’ve got Grade B, let’s do Grade C. Which is if it’s greater than or equal
to 70. And let’s do D as well. And what about Grade U, which is anything below 60%?
Well, we’re just going to put an if statement at the end here saying if it’s less than
60, we’re going to print Grade U. Great. So, this is our script here, now let’s run
it and see how well it works, shall we? OK, so, it asks us for a grade. Let’s enter
“50”. And it says correctly that we got “Grade U”. Great! I mean, the grade isn’t,
but that is correct. But let’s try out the others, make sure it handles them correctly.
Let’s try the grade “92”, so we enter it in and whoa! What’s… Going on here?
Hmm… Yeah this is definitely not right. So, the question is why is it doing this?
Well, let’s take a look at the script, and what we’re going to do is imagine we were
PowerShell reading this script, and let’s see what happens, line-by-line when we enter
“92”. In the next episode, I’m going to show you something very cool that’s going
to help us do this imagining a lot easier, but for now we’ll stick to doing this.
So, imaging “input” was “92”, let’s go through line-by-line and envision what
it’s going to do. So, first it asks whether the percentage is greater than 90. It is,
it’s 90. OK, so it prints grade “A”. That’s correct, that’s what we want we
want it to print. And then if we keep going through, we’ll see it then gets to this
line. This line asks whether it’s greater than 80 and it… Is technically, yes, it
is above 80, it’s 92. So, it… also runs this. I think you can see the problem here.
Then it goes onto this one and yet again it is above 70, so it prints this one out too.
And so on. It doesn’t print the “U” at least because it isn’t below 60, so that
one’s not affected and is fine as it is, but all the rest are affected. What we want
it to do is only print “A, not do all of this, so how can we solve this?
Well, what we need to do is somehow only run all these conditions, these conditions for
the smaller grades, if the grade is not greater than 90. So that way it starts by asking whether
the grade is greater than 90, and only if it’s not does it then start to look at these.
To do that, we can add an “else” to this “if” and put all the other “if”s into
that “else”. So now, if it’s greater than 90, we print this, and that’s it, but
if it’s not greater than 90, then we’re going to check for the lower grades. So this
avoids it doing all of these “if”s when it’s just a Grade A.
Now, we also need to do the same for Grade B, we’re going to handle Grade B, and only
if it’s not Grade B are we then going to check Grade C and Grade D. And the same thing
goes for Grade C, we’re going to check for Grade C, and only if it’s not Grade C are
we then going to check for Grade D. And this works as expected, and I’m going
to show you interactively exactly why it works in the next video in case you don’t already
get it, because I’m going to show you something very exciting next time, called the “debugger”,
it’s a really cool tool that’s going to be so valuable for you to help find bugs and
issues in scripts, it basically lets you watch your code run line-by-line and watch it make
all the decisions with the “if” and such, it’s super useful, and we’ll take a look
at that in next episode and watch this script here run, see it working perfectly.
Also, one thing that’s really bugging me about this script is how ugly it looks. Just…
Look at all this, it’s so… Ugh. It’s so messy and ugly. But there is one PowerShell
feature we can use that lets us do this “else” and “if” in one and that will let us make
this extremely neat, and we’ll find out about that… In the next video.
Bye!
