Is it just me..?

Not sure how others feel but the second half of this lecture was the first time I felt really lost in this course. I sort of understand that Rick is setting up a principle of coding for later use, but in practice the code seems much easier to understand before and just as short (so maybe it was just not a great example?)

He also seemed to speed through this bit as if it was all self explanatory?

Reading the comment below: [Project Boost: Cleaning code here is confusing] made me even more confused :slight_smile:

to quote:

'The value of the blahblahblah variable. void ApplyRotation (float notblahblahblah) and then the variable blahblahblah will be “transfered” to the variable notblahblahblah to use in that code? Exactly. ’

The ‘Exactly’ is doing some really heavy lifting there…

Hoping it will make more sense later on - otherwise, this may be the point I start realising coding is not for me :slight_smile:

Okay…had another stab at understanding it:

We are adding a new parameter to go after ApplyRotation() we are calling this ‘rotationThisFrame’ but it might as well be called ‘blahblahblah’ for our purposes.

Our purpose is: in case we had dozens of ApplyRotations in our script and we wanted different values in each parameter - it looks tidier to have ApplyRotation(changed variable) than:

transform.Rotate(Vector3.forward * rotationThrust * Time.deltaTime);

transform.Rotate(Vector3.forward * -rotationThrust * Time.deltaTime);

etc. times 12

So, by adding a parameter to our method (ApplyRotation) we are saying everything else in our method stays the same except for parameter ( float variable Blahblahblah)

where Blahblahblah/‘rotationThisFrame’ stands in for whatever we want to alter, in this case ‘rotationThrust’ being negative or positive.

Even as I write that my head hurts slightly…hopefully that’s a sign I’m learning something, not that my head is about to explode.

Was also lost here and concerned I sucked at coding. :sweat_smile: There’s a good response here which helped untangle it for me.

In my opinion, what he’s doing there with “extract method” was a bad thing to show with only a single line. It becomes more useful if you’re extracting a complicated piece of code into its own method. Then it shrinks your method length down, and as a bonus you get to tag a specific process (rotating the rocket for example) with your own custom, human-readable name. There are two huge benefits to doing this:
Writing self-documenting code: The basic idea is that somebody who’s never read your code before should be able to easily tell what it’s trying to do.
Modularization: Bits of code that are repeated throughout a project are bad. Having no repeated code makes it easy to upgrade or change things later.

TLDR: You’ll probably be fine not understanding the second half of this one. What he’s saying is good stuff, but in my opinion it’s an advanced concept to cover in a beginner’s course.

1 Like

Reading through your whole post, it seems like you picked up on it eventually. Method parameters is one of the things it took me the longest to really conceptualize in my brain, so don’t feel too lost if it’s takes a while to get the hang of implementing them!

Privacy & Terms