Hoisting Exercise Solution

[00:00:00]
>> Kyle Simpson: All right, let's talk about this exercise on hoisting. We have a inline function expression here. And I said in the lecture that I typically do use one-liner functions as inline function expressions. But just for the purposes of this exercise, let's see what it looks like when we move it out as an in-function expression.

[00:00:24]
And you can then make calls on your own as to whether or not that improves or hampers the readability, okay? So I can pull that out, I have to leave it inside of this scope because it does reference the studentId. I can't pull it out as some standalone helper, it is closed over in using the studentId.

[00:00:44]
But one thing that I do like about this style of pulling things out as function declarations. Is that the places where these functions are used end up reading a lot more cleanly without being interrupted with function execution, definition code. So this reads very cleanly as find, by matching the ID, find a student record by ID.

[00:01:09]
So that style of code of pulling things out, even one-liners, does have some advantages from a readability perspective. Okay, let's do a similar thing down here. We already have a named function being used, so what about this function? Well, we know that that function's not using anything internally, so we could pull it out as its own standalone function.

[00:01:33]
So I will do that, and we will simply reference it by name. Which again, has that readability benefit, now it's much clearer what the sort is doing. Same thing with printRecord, printRecord is essentially a standalone function which can be replaced by a name that references it itself.
>> Kyle Simpson: Now, obviously opinions vary, but my opinion is that produces a lot more readable code to do that.

[00:02:04]
Down to paidStudentsToEnroll, again, we have an inline filter function. This is inline filter function is not using any of the internal variables. So wait, what was that called, needToEnroll, same thing, it could be moved out. And as I said in the intro to the exercise, the reason why we can prefer, from the perspective of function hoisting.

[00:02:33]
The reason why we can prefer moving it to the outer scope is that it is easier, generally, to analyze scopes when they are flatter. The more deeply nested scopes get, the more confusing the closures can happen in places that we're not expecting. So we're trying to move them out to as outer of a scope as we can to try to have a simpler scope model to think about.

[00:02:58]
Okay, getStudentId is a similar thing, it is not referring to anything internally, so that is,
>> Kyle Simpson: One that we can move out.
>> Kyle Simpson: And then, finally, the remindUnpaid, we have this filtering function. Which is, again, not using anything internal, so we can pull it out to this outer scope and use it by name.

[00:03:43]
>> Kyle Simpson: Lastly, we can see that all these functions are at the top. But they don't necessarily need to be at the top because of function hoisting. So what we're going to do is copy all of those,
>> Kyle Simpson: And come down here and put them at the bottom. And then just for general readability, I like to draw ASCII lines.

[00:04:07]
And everything below the line is implementation detail, everything above the line is my executable code. So when I open the file, I see everything right there at the top that's gonna run. As I mentioned in the lecture, I see this as essentially understanding something more detailed about my tool.

[00:04:29]
And using my tool in a way that I think effects a positive change, in this case, for readability. So there are certainly ways that you can use hoisting and make code more confusing. But that doesn't mean that all usages of hoisting are bad. I think there are ways to use hoisting and use function declarations and use nested functions or functions that are pulled out.

[00:04:52]
I think there are ways to do that in which you can make your code more readable. Well, hopefully that's the takeaway you get from this exercise. Is that that's a worthwhile venture for you to analyze about your code.