enforce function statements

[davidjamesstone]

I was wondering about folks preference in regards to expression vs statements.

Clearly it's important to understand the differences between the two in regards hoisting and also the use cases of each but there are often times where either could be used.

I can't find a recommendation - is there a guideline or for this in standardjs?

I see there's the "Enforce Function Style (func-style)" rule in ES Lint. I don't think I'm suggesting this be implemented but it would be nice to have an official line on the preferred approach.

Many thanks

Dave

[dcousens]

Could you post some example code? Probably easier to self-parse and understand what you're referring to?

[davidjamesstone]

Hi Daniel,

Thanks for your reply.

I'm generally referring to 'private' helper type functions that don't have value outside of their enclosing function. Take the save function below.

Here a function expression or declaration would suffice. For consistency, which one should I opt for?

/*
 * Example adding a comment with an optional replyToId
 */
function addComment (body, inReplyToId, callback) {
  // Define the save function with a function declaration
  function save (comment) {
    comment.save(function (err) {
      if (err) {
        callback(err)
      }
      callback(null, comment)
    })
  }

  // The above function could have been a function expression...
  // var save = function (comment) {
  //   comment.save(function (err) {
  //     if (err) {
  //       callback(err)
  //     }
  //     callback(null, comment)
  //   })
  // }

  if (inReplyToId) {
    Comment.findById(inReplyTo, function (err, doc) {
      if (err) {
        callback(err)
      }
      save(new Comment({ body: body, inReplyTo: doc.id }))
    })
  } else {
    save(new Comment({ body: body }))
  }
}

Hope this helps

Dave

[dcousens]

I personally opt for function save, but I don't think there is a hard-rule for this in standard.

Maybe there should be.

@feross ?

[rstacruz]

xo has one. I don't mind it.

[davidjamesstone]

Likewise I have opted for function save () {...} in the past. This is the also the advice from Crockford.

More recently though I have noticed people using var save = function () {...} a lot more.

While I don't have a strong preference, I would like to see some consistency within code base/across teams.

[dcousens]

More recently though I have noticed people using var save = function () {...} a lot more.

Probably because you have to use that syntax if you are using context capturing lambdas:

var save = () => {}

[cesarandreu]

I use arrow functions with callbacks or when I need to preserve context.

I'm not sure this holds true anymore, since it seems most engines have improved this by now... But it used to be that the following would give you worse stack traces:

// Anonymous function
const foo = function () {}

// Could be fixed by giving it a name
const foo = function foo () {}

With babel the default behavior seems to be to name the function:

// Before
const foo = () => {}


// After
const foo = function foo () {}

I'm a fan of function declarations since it tends to encourages writing pure functions.

[feross]

Function declarations are preferred.

Function declarations have more intuitive hoisting behavior, i.e. you can use the function anywhere that's in-scope. With function expressions, only the variable is hoisted, so you can only use the function after the line where the assignment occurs.

[feross]

Just tried enabling func-style to enforce function declarations, while making an exception for arrow function expressions, and got this result:

# tests 427
# pass  331
# fail  96

Full output: https://gist.github.com/feross/0d57fdddde82f55d618a

It's a high number, so leaning toward not enabling this. Much as I like it. Maybe if we do standard-strict?

[feross]

For documentation, here's the rule I tested with:

"func-style": [2, "declaration", { "allowArrowFunctions": true }]

[dcousens]

@feross how about V6? I think it is a reasonable enough change and absolutely in the spirit of our existing rules.

[feross]

@dcousens Agreed, but it's quite a bit of breakage (22% of the ecosystem).

[dcousens]

@feross it is also a break that could probably be resolved with a regex. We could provide / run it for them even.

[dcousens]

For VIM users

%sno/var \(\.\+\) = function \.\*(/function \1 (/gc

[feross]

closing - we can move discussion of potential "next gen" or big breaking rule to the standard-strict issue: #382