Use function expressions instead of declarations - JavaScript Tutorial

- [Instructor] JavaScript provides a number of options for function syntax. The most basic distinction is whether to write a function declaration or a function expression. A function declaration starts with a keyword function, followed by the function name, parens, and then braces, A function declaration makes it clear from the start that the statement creates a function. The other primary approach is a function expression, which contains all the same parts, just in a different order, and importantly, with some differences under the hood. A function expression starts with a keyword to create a variable. I use conts for all my functions, because I generally don't plan to change them in my code. But depending on your code style, you could create a custom expression with LET, or even VAR. After the variable keyword comes the function name, an equal sign, then the function keyword, parens, and braces. Although both syntaxes support the main parts of a function, there are a couple differences in how they work. Most significantly, function declarations are hoisted, while function expressions aren't. Hoisting, in a nutshell, means that when a function declaration is present anywhere in your code, the parser makes it immediately available, treating it as if it had occurred before the first line of code. A function expression, on the other hand, is subject to the more nuanced hoisting rules based on which variable keyword you use. For function expressions like mine, created with const, nothing is hoisted. Hoisting may sound like a great thing, but the general consensus is that it encourages writing code that's harder for humans, like your team members, to understand. For that reason, function expressions are widely considered the best practice when creating functions. In the code for this video I've created a variable containing the date. I want to create another variable that stores the date a week ago, and to do so, I want to create a reusable utility function. I've included the statements that go inside the function as comments in the start file. I'll go ahead and create a function declaration. That's going to be function, week ago, date. And then I will cut and paste those lines of code inside my function, and I will uncomment them. Then below the function I'll add a statement to create my new variable and to call the function to return the value. So that'll be a const called 'week ago,' and I'm just going to call week ago, date, and get that value from that function. I'll save that. Then I'll go live with my HTML file. I'll open up my console in the browser, and I see my date's logged to output, and I have today and then seven days ago. So far, so good. Now, in my JavaScript it can be tempting to group all my single value variables together. So let's see what happens if I do that. I'll move that 'week ago' variable up to the top below the today variable. And I'll save that. And back in my browser everything still works just fine. I get the same results, no errors. And this is because of hoisting. The 'week ago' date function is available from the first line of code in my file, even though it's not defined until later. There's a certain appeal to this code organization. I can put all the code at the top that's actually doing something. I could even move my console dot log statements here, and then banish the function declaration to the bottom of file, so I don't have to scroll past it to see these statements that are generating output. The problem is that it can be hard to understand what's going on. What is the 'week ago' date statement doing? Where is that code? Especially in a file that contains a lot of code, it can be harder to find. Now, what happens if I use a function expression instead? I can implement that pretty easily. So I'll use const, and the first line of my function becomes const. We could go date equals function, and then the same syntax from that point forward. I'll save that. And back in my browser, now I have an uncaught reference error. Can't access lexical declaration 'week ago date' before initialization. And that makes sense because the function hasn't been defined at this point in the code. This may seem less convenient, but it means that instead of relying on the parser to move things around for me, I'm going to make my code read from top to bottom. And any function I use will already have been defined before I reference it. With the parser enforcing that for me, I have to organize my own code. To make my function expression work, all I need to do is move that 'week ago' declaration below the function. So I'll move that back down... And save. And now, back in my browser console everything works again. ESLint can help keep me on the right track as I'm developing with the func-style rule. This rule ensures that ESLint throws an error if I use a function declaration. So I'll always need to be thoughtful about calling functions only after I create them. In my ESLint RC file... In the rule section I'm going to add the statement "func dash style," and because that has a hyphen in it, which is not a legal property name in a function, I have to include that in quotes. And then as the value... It's going to be an array, and that'll be error, expression. Ending that with a comma. I'll save that. And back in my code there's no errors flagged in the editor because I'm already using a function expression. So my function is using best practices, and now I have an ESLint rule in place to help me remember to stick to function expressions going forward.