Original subtitles

When your code is full of bugs, you're going to often wonder, why is my code behaving like this?

In this lesson, you're going to learn how to debug using breakpoints.

You can load the code for this lesson by following this path, if you don't see this path inside your

resources, then make sure to download the updated resources from GitHub.

Now, looking at the code, it seems like the intent is to return a random number between one and three.

And so the option variable should randomly equal hits stay or fold, so ideally the code should randomly

print, hit, stay or fold.

But if you're on the code.

It's always going to print Brentford.

How strange, using breakpoints, we can visualize the runtime, so I'm going to add breakpoints everywhere

for now.

I'm going to launch a new debugging session.

Launch current file.

And I'm going to step through every line to visualize what's going on.

All right, and now if you keep restarting the debugging session, notice the random number never equals

one or two.

It's always three three, three, three.

So stop the session, and my first instinct now is that we're not defining the random value correctly,

so remove all the breakpoints.

In a two break points right here.

Now, I'm going to start another debugging session.

And press continue.

And no matter how many times you restart the session, the random value is always three.

This means for sure we're not defining the random value correctly.

Let's do the math if math orendain, returns point one.

And point one equals zero.

OK, what if and returns a high number like point nine, once again, typecasting, point nine first

is going to equal zero.

So no matter what, the random value is going to be three, because the arithmetic operation starts

by typecasting the decimal to zero.

So we're going to do is add brackets to ensure that doesn't happen.

All right, make sure you've already stopped the current session, then launch a new debugging session.

Once again, the value is always three.

Let's do the math again, if not the random returns to point one point, one times one plus three is

equal to three point one typecasting.

That gives us three.

OK, if it returns point nine point nine times one plus three equals three point nine typecasting.

That is going to return three as well.

I see.

What's wrong now, waps.

I should be multiplying the random value by three, then adding one.

All right, make sure to stop the current session and launch a new debugging session.

And perfect, it picks randomly between one, two and three.

Now, stop the debugging session and switch from the debug console to the terminal.

And now run your code to see if that fix our problem.

And it keeps folding.

We know that the random value works perfectly now, so maybe Switch isn't setting the option variable

equal to the correct value.

So we're going at a break point before every case to test this part of our code.

Launch a new debugging session.

Aha, the correct case executes, but switch runs every case that follows the case much, eventually

the value isn't going to be what it should.

So I need to add the breaking word after every case.

All right, longitude debugging session.

And we're good now, so as you can see, great points are a great way to make sure different parts of

your code are working properly.

First, we used the breakpoint to make sure the variable equals random values of one to three.

And then we used break points to make sure the switch statement is working properly.

And now the code should be free of bugs or is it let's rerun the code.

OK, I know that the random variable is fine, the switch statement works properly.

So the if condition must be Iraq at a break point next to the condition, print statements debug the

code.

And now it's clear that the statement runs, no matter what the option is, even though the option is

stay the statement or wrongfully executes the true and runs the code that would Folt.

And so looking at the condition, we can quickly identify the problem, fold should only print the option

that doesn't equal hit.

And if it doesn't equal stay in this case, the operator is not appropriate.

Assuming option equals hit, the first condition is false and the second condition is going to be true.

Executing the if block.

In this case, the option will stay.

The first condition is true and the second condition would be false.

And once again, executing the if block.

So replaced your operator with the end operator, and now I'm going to keep restarting the debugging

session until I've tested every scenario.

Perfect, first it stays.

Now the option is fold, so the extension should run.

OK, now the option is hit.

So the estimate would get skipped and indeed it does.

Great, now I'm fully confident that my code is free of bugs so I can safely remove all of my breakpoints

and rerun the code.

Don't spam print line statements, don't debug by spamming print line, putting print lines all over

your code is messy.

It's going to annoy other developers working in the same code base and it doesn't paint the full picture.

Instead, use breakpoints to visualize the runtime, the track, the state of your application Line-by-line.

Let's recap, we used breakpoints to debug an application and breakpoints are a very powerful debugging

feature, you can just visualize what's going on from point A to point B.