change function syntax

[RealWeeks]

I think setting it up like this will cause great confusion:

const product = function product() {

};

Should be changed to:

const product = function () {
};

[RealWeeks]

Did cause great confusion

[jrhorn424]

const product = function product() {

This pattern used to have great value in debugging. Note that

const product = function () {

cannot be used recursively.

[jrhorn424]

I don't think I want to change this. It's a "teachable moment" and IMO an example of institutional knowledge being present in a README as well as in my head. The problem here is that the README does not mention:

1. anonymous functions sometimes give difficulty in debugging (less likely nowadays)
2. anonymous functions cannot be called recursively

[RealWeeks]

To clarify this did cause great confusion. We had to change the way it was taught mis lesson to keep students on board.

[gaand]

It's a scope of names discussion.

const foo = function bar () {

};

The scope of foo is the enclosing scope, whatever that might be.

The scope of bar is the function body.

This causes some heads to explode.

Stack traces including bar do have benefits (for those who don't read carefully :-P.).

[jrhorn424]

I mentioned this during WDI 12 and didn't really experience much confusion during the lesson. I told them they could leave the function declaration name off and just use the assigned name.

[gaand]

I'm not sure what you mean by "function declaration name". The syntax I used in my comments are function expressions. Adding the name does not create a declaration.

function bar() {return "bar declared";}
const foo = function bar() {return "bar expression";}

The second bar shadows the first inside the function stored in foo, and allows for recursive calls, but other than it doesn't do anything.

So the two snippets of code, function bar() behave differently.

It was an issue for 009, 010, 011. I seem to remember it coming up when we told them not to use the declaration form.

After typing for a bit I realize this may be too deep a point for WDI Developers, and the confusion may have come from my attempt to ensure they understood the distinction.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/function

[jrhorn424]

I'm not sure what you mean by "function declaration name".

const foo = function bar() {return "bar expression";}
// i meant this ------^

his may be too deep a point

Maybe so. I glossed over the distinction, most likely because I couldn't express it in English. My "explanation" went: "There are two ways to define functions. You should use this way (expression), not that (declaration). If you want to call the function recursively, or if you want to improve debugging, do both."

[gaand]

Just to be a pedant, the bar there isn't part of a function declaration, it's part of a function expression, so your gloss may have avoided the confusion, but isn't technically correct. The name is only part of a function declaration if it's not a function expression (assignment or passed immediately) and in that case the name is visible in the scope containing the declaration. You apporach may still be better than what I did, since I confused some developers in three separate cohorts.

Restating, a name in a function expression isn't visible in the containing scope, just the function body. A name in a function declaration is visible in the containing scope.

Are we having fun yet?

So, the pedagogical point may be that I shouldn't try to make this distinction clear. I think that's probably correct and difficult for me to do.:-).

Advice on on how I might achieve that would be useful. Or maybe Jason's original point of just leaving it out would be best for me.

[payne-chris-r]

I think the best course of action is to tell them,

Hey, you can declare your functions this way:

const product = function product() {

};

OR this way:

const product = function () {
};

The reason you MAY want to declare them the original way involves recursion and should only be used when you need to call the function you're declaring within the function itself.

IF what I just said makes your head spin, declare your functions like this until you have a better grasp on javascript:

const product = function() {

};

Thoughts? @J-Weeks @gaand @jrhorn424 ?

[jrhorn424]

Honestly we can leave it out at this point. This is a great discussion and I learned a bit. Thanks @gaand for taking the time to explain and @J-Weeks for posting.

My original resistance and the strongest point I've made is that debugging used to suck without putting a name on both sides of the assignment. I haven't experienced that much lately, and I use simple function expressions everywhere else in the curriculum, so I suspect I would have noticed the pain.

[gaand]

We might want to be consistent and only do it one(*) way:

const snafu = function (param) {
}

const fubar = () => {
};

(*) where one is two.

[gaand]

Please see ga-wdi-boston/js-modules-study#17 as well.

[gaand]

@ga-wdi-boston/core May we settle on my suggestion for all JavaScript functions not defined as methods, or would someone like to make a reasoned counter argument?

[jrhorn424]

@gaand I consider this settled and agree with your convention. Is this an accurate summary?

// GOOD
const foo = function () { };

// GOOD if needed for recursion
const bar = function bar () {};

// BAD otherwise
const baz = function baz () {};

[jrhorn424]

Is fat arrow appropriate? Or do we want to track that separately?