Statements, Declarations and Expressions. Which is which?

Hi Richard,

Good questions.

So the first example is a declaration because you are "declaring" here is a function!

The second one, you are actually not naming the function, but putting it in a variable with a name. This, I believe does have some implications you have mentioned with hoisting.

Hoisting is the way JavaScript processes variable. Say you have a function as follows

var myFunc = function() {
//stuff

//more stuff

// even more stuff
var aVariable = 100;

}

JavaScript will process this as if the variable was declared at the top of the function. This is hoisting. Taking the variable and declaring them at the top. Simple process, scary name. The code will be processed like this:

var myFunc = function() {
var aVariable;
//stuff

//more stuff

// even more stuff
 aVariable = 100;

}

Anyway, hope this helps . . .

The course was great, by the way. It helped clear up a few hazy concepts in my head. Looking forward to the next course on loops, arrays and objects.

I'll stop bugging you now, go have candy! XD

And thanks again!

R

I've copied this verbatim from the following article:

http://www.unicodegirl.com/function-statement-versus-function-expression.html

Some of the assertions in the article are a little confusing, so I have emphasized my own comments and question throughout the article.

Begin Article...

Function Smackdown: Function Statement vs. Function Expression

I’ve recently been reading ‘JavaScript: The Good Parts,’ by Douglas Crockford. This concise book defines a subset of core JavaScript that’s robust and powerful: The Good Parts. Appendix B identifies The Bad Parts, and sets our competitors - the function statement and the function expression - apart.

ROUND ONE - LOOKS (CAN BE DECEIVING)

Function Statement (does this person mean declaration?)

Our competitors may look alike, but the function statement has two distinguishing characteristics: the declarative keyword function always comes first, and you must name it. Here’s what it looks like:

//what we see:
function funcName(){
     //stuff
}

Pull back the curtain (what curtain?) , though, and the function statement expands into a variable with a function value:

// Under the hood
var funcName = function funcName(){
     //stuff
}

Function Expression

Absent the mark of the function statement, you have the function expression. The function expression is optionally named (but normally anonymous), e.g.:

// Stores ref. to anonymous function in a variable 
var funcRef = function(){
     //stuff
};

// Stores ref. to named function in a variable 
var funcRef = function funcName(){
     //stuff
};

WINNER: Function Expression. Crockford’s manual argues the case for clear code. The function expression is clearly recognisable as what it really is (a variable with a function value). is this what the browser does to a function? and do all browsers behave similarly?

ROUND TWO - (UNPREDICTABLE) BEHAVIOUR

Function Expression

Variables are subject to a thing called hoisting. Irrespective of their apparent place in the flow of things, their var part is removed and hauled to the top of a containing (whether function or global) scope, and initalised with undefined: (is this part of the 'under the hood' part?)

// What we see
var funcRef = function(){
     //stuff
};

// Under the hood
var funcRef = undefined;
funcRef = function(){
     //stuff
};

Function Statement (again, declaration?)

The function statement - while just shorthand for a var statement with a function value - is treated differently: the whole lot is hoisted. For this reason, you can call a function statement before you have declared it in your code:

console.log(statement()); // I am a function statement.
console.log(expression()); // TypeError...

function statement(){  
  return "I am a function statement.";
}

var expression = function(){
  return "I am a function expression.";
}

WINNER: Function Expression. Hoisting is already a behind-the-scenes behaviour that can cause head scratching. The particular behaviour of the function statement can lead to more furious head scratching.

ROUND THREE - SUPER POWERS

Function Statement (you know.)

The function statement is widely used and performs just fine, but it has an obvious limitation: You can’t immediately invoke it.

Function Expression

The function expression is more flexible, e.g.:

// Executed immediately
(function() {
   alert("I am not a function statement.");
}());

Parentheses are required to nudge function out of statement position (can’t immediately invoke), and into expression position (can immediately invoke). Crockford recommends grouping the entire invocation inside parentheses for clarity - what’s important here is the product of the invoked function - otherwise, Crockford argues, “you’ve got these things hanging outside of it looking like dog balls.”

WINNER: Function Expression.

FINAL SCORE: Function Expression Wins 3 - 0

CONCLUSION - I HEART A GOOD MANUAL

It turns out the function statement came first; the function expression was added to JavaScript later. The result is two very similar ways of defining JavaScript functions. Logically, the addition was intended to improve the language, and, in this case, it would seem this end was achieved.

... End Article.

So, this is all very interesting and confusing and making my head run around in circles about all this stuff. Just curious to get everybody's thoughts on these assertions and try to get a more balanced perspective.

Again, thank you! XD

Richard Nash