Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
Let's use what we learned about static methods and the Math class to finish coding up the DistanceTo method.

0:00
Now that we know how to use the static square root method in the math class,

0:04
let's use it to finish coding up the DistanceTo method, in the Point class.

0:08
The last thing we needed to do to complete the Cartesian distance formula,

0:13
is to add these two values together and take the square root.

0:17
We can actually do that in a single statement.

0:21
We can say Math.Sqrt of xDiffSquared + yDiffSquared.

0:32
There we go.

0:33
We've coded up the cartesian distance formula.

0:36
Now we just need to return the result.

0:41
Let's test our method in main.

0:43
Let's clear out this code and then get the distance between

0:49
this point at (4, 2) and the coordinates at (5,

0:54
5) and print the result using console.rightline.

1:02
Now let's open the console to compile and run this.

1:13
Looks like we got a compiler error.

1:15
It says the name Math does not exist in the current context.

1:18
And this is back in the point.cs file, line 22.

1:22
So let's go back there.

1:25
I see.

1:25
We forgot to add the using System.

1:34
All right.

1:35
Let's run this again.

1:38
Here's another compiler error.

1:39
It says cannot implicitly convert type double to int.

1:44
And this is in point.cs, line twenty four.

1:50
Again they're Math.Sqrt.

1:54
This error must be saying that it can't convert the double

1:57
that's returned from Math.Sqrt to an integer.

2:01
Remember that the documentation for Math.Sqrt said it returns a double?

2:06
This is one of those rare times when we don't care about the decimal value

2:10
of the result.

2:12
We're only using whole numbers in our game.

2:15
An invader can't be halfway between two grid squares.

2:19
Truncating the decimal value we get from this formula

2:21
gives us the correct distance in discrete units.

2:25
Remember that when we cast a double to an integer

2:27
it removes the decimal portion of the value.

2:30
This is called truncation.

2:32
And that's what we want to do.

2:34
So we can just type int.

2:35
in parentheses here to get the desired effect.

2:39
This will cast the result of Math.Sqrt to an integer.

2:43
Now let's save, compile and run again.

2:48
All right so we see the result is three.

2:51
So the distance between point (4, 2) and coordinate (5,5) is 3.

2:55
If you like, you can verify on a calculator that this is correct.

3:01
Let's take a final look at the DistanceTo method before we move on.

3:06
There are five lines in the DistanceTo method.

3:10
It might surprise you to hear that we could have written all this in a single

3:13
line of code.

3:15
Let me type it here underneath the existing code.

3:18
Then we can talk about why we might prefer one way over the other.

3:22
So the cartesian distance formula is the square root

3:31
Of the sum of the square for this.

3:38
We use another method in the math class called POW for power.

3:42
This allows us to raise a value to a power.

3:45
In this case, two.

3:56
So we have the square root of the sum of the squared differences.

4:02
So we get X minus x and Y minus y so this code here,

4:09
does the exact same thing as this code up here.

4:17
As you can see it puts the entire math formula on a single line.

4:22
One advantage of putting the code all in the same line,

4:25
is that it gets rid of most of the variables.

4:27
The fewer variables there are,

4:29
the less likely you are to type the wrong one in the wrong place.

4:34
Say, for example, that I typed xDiff here instead of yDiff.

4:40
>> That's a very common mistake when programming.

4:43
Because the variables look so similar, it's not obvious what the problem is.

4:48
Just because you can put all the code on a single line, doesn't mean you should.

4:52
In fact, this is actually a good approach to programming.

4:57
You see, by coding it this way,

4:59
we've broken up the solution into smaller parts that are easier to think about.

5:03
Solutions that are easier to think about are easier to code.

5:08
Once you think you have a correct solution implemented,

5:12
you can test it with known values.

5:14
After you verify that the solution is correct, you can always go back and

5:18
refactor the code into a less verbose form.

5:21
Then run the same tests again to verify that the changes didn't break anything.

5:26
This is a very common pattern for designing, refactoring, optimizing and

5:31
refining software.
You need to sign up for Treehouse in order to download course files.
Sign up