Space after function keyword in anonymous functions

[lydell]

NOTE: This issue is raised due to confusion in #1139.

This issue is only about anonymous functions:

const identity = function (value) {
  //                     ^ space here
  return value;
}

(Prettier currently does not put a space there.)

🗒 NOTE: This issue is not about having a space after the function name:

function identity (value) {
  //             ^ space here: SEE #3845!
  return value;
}

Space after function name is tracked in #3845!

The key argument is:
Consistency: This means that there's always a space after the function keyword.

[allex]

why not provide a --space-before-function-paren option

[azz]

@allex please read https://prettier.io/docs/en/option-philosophy.html

[alexburner]

+1 for space after function keyword. Crockford supports this:

If a function literal is anonymous, there should be one space between the word function and the ( left parenthesis. If the space is omitted, then it can appear that the function's name is function, which is an incorrect reading.

[allex]

y, For a generic tools, we need keep simple options as possible. but lots of project lint with standard with the space-before-fuction-paren enabled by the default.

[k15a]

@allex Don't lint stylistic issues when you use Prettier and all the problems are gone.

If you say that generic tools should provide simple options why is standard not providing an option to turn stylistic linting off?

[j-f1]

How should a generator function be formatted?

const identity = function *(value) {
  //                     ^ space here
  return value;
}

// or:
const identity = function* (value) {
  //                      ^ space here
  return value;
}

// or:
const identity = function * (value) {
  //                     ^ ^ spaces here
  return value;
}

[lydell]

Since this is all about consistency with named functions, the spaces should be exactly like for a named generator function. function* gen() {} and function* () {}

[josephfrazier]

I agree with @lydell. In this case, I'd consider the keyword to be function*, not function.

[coolemur]

Just something to mention:

Yes, you can turn off your linters and use whatever predefined style "Prettier" offers.

But when you consider a project template that comes with default linter rules on and you have N projects to create (and by N I mean "many"), it is not efficient to turn linters in every project. It would be more efficient to adapt prettier options.

I am never a fan of forced rules. Let it be a default (recommended) set of rules and let us tweak them so they would be flexible enough to work with projects which have their own code styles.

That would be fair enough.

[j-f1]

Let it be a default (recommended) set of rules and let us tweak them so they would be flexible enough to work with projects which have their own code styles.

https://prettier.io/docs/en/option-philosophy.html