Prettier: Space after function keyword - MOVED to #3847!

[sparty02]

I apologize in advance if this has been discussed before (I did a quick search and didn't find it). One of the things that popped out when running prettier over our codebase was spacing on anonymous functions.

For example, prettier converts this:

function foo() {
  this.bar = function () {
    console.log('baz');
  }
}

into this:

function foo() {
  this.bar = function() {
    console.log('baz');
  }
}

While this pattern is becoming less common for us (we'd probably use an arrow function here now), we still have several cases of this. The lack of space after the function keyword just doesn't read right for me. It probably has to do with one or more of the following:

1. It looks more like a function invocation than a declaration.
2. The lack of space after a keyword is odd.

For prior art:

• https://github.com/airbnb/javascript#functions--signature-spacing
• http://eslint.org/docs/rules/space-before-function-paren
• http://eslint.org/docs/rules/space-after-keywords

Are there strong feelings on this one?

[hawkrives]

Personally, I prefer to omit the space when I make an anonymous function?

Now that I'm thinking about it, though, I don't know when I last wrote an anonymous function() (I've moved pretty thoroughly to ES6 and using arrows as my anonymous funcs), so I could likely adapt to having a space there.

[sparty02]

FWIW, here's a diff of the change in a potential PR (at least me taking a crack at it!).

[pakastin]

I'd also write function foo () {

[trevorgerhardt]

This also appears to be the only rule that conflicts with standard after the 1.0 release.

[adonis-work]

It also conflicts with standards jsq-quotes rule, but that might be a bug in forcing double quotes to overwrite single quotes in jsx while singleQuotes:true is in config.

[jlongster]

We're not going to change this. It's a very bike-sheddy debate and doesn't really matter. You might be used to seeing it the other way, but prettier has already made a choice and this and we're not going to change it. If you want to add a space there, you can run your code through prettier and than through an eslint config that adds it with eslint --fix. It's comment for prettier/eslint integrations to do this (see prettier-standard-formatter).

[bhanuc]

Any chance of making this configurable ? This issue possibly breaks space-before-function-paren and generator-star-spacing for my eslint checker.

[lydell]

@bhanuc What not just disable those rules? What do they gain you when using prettier? :)

[rhengles]

@bhanuc I would accept a PR for this in arijs/prettier-miscellaneous

[chanlito]

Many people are using standard with prettier i think this should be an option with prettier.

[justrhysism]

The space before a function parentheses is a minor visual cue that the author is declaring a function, and not calling one - aiding readability.

At the very least, as others have suggested, it should be an option.

[jlongster]

We strongly recommend disabling any formatting rules with eslint-config-prettier (just list it after standard and it'll turn them all of). We aren't going to add options for such small changes, as if we did, we'd have to add options for a lot of other things. It's good for the JS community to stabilize on a general style (and as far as I'm concerned the majority of JS does not use a space). It doesn't really help readability in my opinion, you just might need to retrain how you see that pattern.

[srhise]

This causes linting issues on any project using vue-cli

[chanlito]

@srhise i think prettier was created with react in mind.

[srhise]

Yeah, i'm not a huge fan of the default linting rules used in vue-cli. Very strict.

[matthewmueller]

This decision doesn't make a lot of sense to me. If the goal is to be opinionated with no bike-shedding, why are there any options at all? Seems like if there is even 1 option (ex. single vs double quotes) then other options should be up for discussion.

Most people were using standard to fix their code before prettier came along. Though I don't care much which way we head (spaces or no spaces before parens), I'd like to see a consensus reached between the two projects.

I think a nice separation would be to use prettier to format your code and standard to lint your code. Right now they're conflicting with each other and therefore need either double parsing and fixing (e.g. prettier-standard) or custom eslint configuration for each project, both of which aren't ideal.

[chanlito]

Now that u mentioned single vs double quotes option, i think something like space_before_function_paren options: boolean seems a good choice. unless it's hard to implement.

[josephfrazier]

I just added --space-before-function-paren to prettier-miscellaneous, if anyone wants to use that instead. See https://github.com/arijs/prettier-miscellaneous/issues/22 for details.

[austinkelleher]

tl;dr

Providing an option for a space before function parens can improve project search quality.

Argument

So I read through this thread and I understand both sides of the argument, but I want to throw out an additional note regarding spaces after functions that hasn't been mentioned. For me, the space after a function name is particularly useful for searching projects. In large projects with potentially hundreds of function calls to the same function, searching for a function definition can be challenging. Having a space after a function name can help narrow (and often point exactly to) the function definition:

Helpful scenarios

class Person {
  sayName () {

  }
}

function sayName () {

}

module.exports = function sayName () {

}

Less helpful scenarios

// say-name.js
module.exports = function () {
  // Say the name
}

const sayName = function () {

}

let sayName

sayName = function () {

}

Conclusion

Many functions are defined like the top 3 scenarios. I've found a space before function parens very useful to quickly find function definitions in a project, or at least narrow the search results to something that is more manageable. As shown above, there are several scenarios where this isn't as helpful, but ultimately I think that having an option in prettier would prove to not only be helpful to those who are coming from Standard, but also improving search quality.

[aboyton]

And to think I've been searching for n sayName() anytime I want to find a function. Personally I don't really care what one you pick (personally I think sayName() is prettier to read, and finding the definition of a function should be a feature of your editor IMO), but either way, less options the better. The whole point of prettier is that code is consistent and to not have bike shedding.

[joseluisq]

__VS Code Tip:__
If someone uses VS Code could try prettier-now-vscode extension for to take advantage of space-before-function-paren via prettier-miscellaneous.

For example: Here my default settings for prettier-now-vscode :

    "prettier.singleQuote": true,
    "prettier.trailingComma": "none",
    "prettier.semi": false,
    "prettier.useTabs": false,
    "prettier.tabWidth": 2,
    "prettier.spaceBeforeFunctionParen": true

[lmk123]

I'm using VS Code + TypeScript + Vue.js + Prettier Plugin + JavaScript Standard Style in my project, and I experience this issue.

Prettier format my code without space before function parenthesis, I know there is prettier-eslint can auto fix it, but it doesn't support tslint. And, typescript-eslint-parser is not stable yet.

So I run tslint --fix from CLI every time before I push my files, but tslint doesn't support *.vue so it can't fix code in *.vue file.

After that I installed Vetur, an VS Code plugin from Vue.js team, it use Prettier to format script in *.vue, but because of Prettier doesn't support space before function parenthesis, it also delete the space before function parenthesis.

Finally, I disabled space-before-function-paren rule.

Maybe I'm selfish —— I apologize in advance if I'm wrong —— if Prettier support this rule, I think it's easy to avoid upon problems for people who use TypeScript, Vue.js and JavaScript Standard Style just like me.

[lydell]

Current instruction:

Disable the space-before-function-paren ESLint rule.

If Prettier adds support for printing that space:

Use the --space-before-function-paren Prettier option.

That’s no easier, is it?

[azz]

While we don't recommend using style rules in conjunction with Prettier, I recently published https://github.com/azz/prettier-tslint which may solve part of the problem.

[noahdecoco]

If you're trying to get this to work with the Vue CLI, just add this line as one of the rules in the .eslintrc.js file in the root folder...

'space-before-function-paren': 0

[chanlito]

Hmmm, maintainer must hate this space-before-function-paren rule that much huh?

[srhise]

That's what I was saying haha.

Sean Hise

On Tue, Oct 31, 2017 at 2:32 AM, Bruce Hem [e-mail] wrote:

Hmmm, maintainer must hate this space-before-function-paren rule that much
huh?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prettier/prettier/issues/1139#issuecomment-340673080,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3ywagumERKlHWWAg7ydn4RevyCqLOUks5sxr7_gaJpZM4M1Csc
.

[Aanhane]

I agree with @lmk123 (https://github.com/prettier/prettier/issues/1139#issuecomment-337828872)

For anybody that came here because you are running a VueCLI project with VSCode and Vetur, it helps to just switch from prettier to the VSCode formatter by editing your settings like so:
"vetur.format.defaultFormatter.js": "vscode-typescript",
"vetur.format.defaultFormatter.html": "js-beautify-html",
"javascript.format.insertSpaceBeforeFunctionParenthesis": true,

The javascript format settings for VSCode are a bit more flexible than prettier, so it works well with Vue CLI.

I think, because of VSCode also supporting it, you should really reconsider adding this. For me personally, it feels strange to disable a formatting rule because the tooling doesn't support it. I rather prefer setting an option to maintain a rule, rather than setting an option to disable it.

@lydell (https://github.com/prettier/prettier/issues/1139#issuecomment-337833555) while both are indeed one line of code, one reduces the legibility of my code, the other one allows me to maintain that. That is the reason I think this option should be added.

[lydell]

@Aanhane Sorry, that comment was an answer to lmk123’s comment just above specifically, not to this issue in general.

[chuyik]

If there's option like bracket-spacing and semi, why not space-before-function-paren?

I really want to use prettier instead of ESLint on a existing large project though, but the switch will lead to huge code changes because of this.

[azz]

@chuyik Have you looked at https://github.com/prettier/prettier-eslint ?

[johnmerced]

I'm looking for this options as well! Hopefully it's added in the future.

[xgdgsc]

Do you have any pre-defined mechanism for reconsidering design choices like this. Or you just do whatever you prefer and ignore other people' s preference (THE STANDARD)? I now get why you put "Opinionated" on your description.

[NikxDa]

I'd like @jlongster to rethink this design decision as well, not as a standard, but as an optional flag. This pattern is seen in a huge amount of large codebases and if prettier wants to gain an even bigger audience, it should be able to handle simple rules like this, even if it calls itself "opinionated" (whatever that means, there are several other options which are solely based on preference as well).

Plus: 1.9 has been released, adding support for (x) => {} instead of x => {}. A change like this is not opinionated as well, so the change requested in this issue should be no problem to add.

[paulocoghi]

With standards like this, Prettier is making my code uglier and less readable.

Comparing the use of https://github.com/prettier/prettier-eslint or just ESLint, the latter makes more sense to me.

[goowikns]

Seems like EA all over again... With all due respect to the devs but is it really that hard to listen to the community?

[emveeoh]

Another voice requesting the addition of 'space-before-function-paren': true

[0x0006e]

bad...

[justrhysism]

@jlongster you seem to believe that the community doesn't care, but the noise on this issue is pretty constant for 9 months now - would it worth at least creating a poll to actually get the community voice (since the upvotes/downvotes on this issue apparently don't seem to count).

I understand that Prettier is opinionated - I agree with most of the decisions made by the Prettier team, with the exceptions of tabs (yes), trailing commas (es5) and spaces before function declaration parenthesis (yes). There are configurable options for the first two.

[drudv]

[EmilyRosina]

++ to all who want THE OPTION; then everyone is happy!

Anyone else using VS Code though.. in the meantime I had to disable Prettier to get Prettier Now's spaceBeforeFunctionParen to work 🤕 at least i can get on coding again now!

[chanlito]

@EmilyRosina yes, but it doesn't work with .vue files.

[Aanhane]

@BruceHem try enabling the VS Code formatter for Vue, and configure the formatter to conform to the lint config from vue-cli. (also see https://github.com/prettier/prettier/issues/1139#issuecomment-341964133).

[EmilyRosina]

@BruceHem Ahh true.. i'm learning React and this plugin was advised, but for Vue i use Vetur
@Aanhane i'm not sure your answer gives enough explanation as to how to achieve what you're suggesting.. although tbf your previous answer is clearer

[azz]

++ to all who want THE OPTION; then everyone is happy!

Except the maintainers, and every person who has to rationalise to their team why the chose to turn the option on or off. There are _large_ hidden cost to options.

[srhise]

I understand what you are saying but if this is standardized between React
and Vue it would really help the overall developer experience across the
top two JavaScript frameworks.

On Mon, Jan 22, 2018 at 8:34 AM Lucas Azzola [e-mail]
wrote:

++ to all who want THE OPTION; then everyone is happy!

Except the maintainers, and every person who has to rationalise to their
team why the chose to turn the option on or off. There are large hidden
cost to options.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prettier/prettier/issues/1139#issuecomment-359424470,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3ywcONiPk_UNg3l3KlVSOnzfL8VXrWks5tNI5wgaJpZM4M1Csc
.

>

Sean Hise
CEO & Co-Founder
Crafted
p: [phone]
w: craftedup.com e: [email protected]

[NikxDa]

@azz When the default value is kept, teams that are already running Prettier will not be affected. I do not see why the "needs discussion" label is removed, this issue definitely needs discussion, whether you like it or not. Prettier has a large audience after all, and this issue demonstrates that there is no consensus among its community.

[stepli1010]

when use prettier every time, i have to modify the space before fun, it is annoyed.

[MysticEarth]

Would love this option as well! Why not support this as well instead of discussing it? Other options are available as well...

[j-f1]

Other options are available as well...

If that was sufficient rationale to add another option, we’d have far too many options to test against and maintain. See #40 for our general policy discussion on the topic of options.

[MysticEarth]

I get your point, but what's the criteria for something to become an option then? This particular option seems to be highly requested and could make Prettier work for people using vue-cli as well. I just don't see why an option like Bracket Spacing exists and the discussion about space before function paren is being ended with your general policy discussion...

[lydell]

The truth about the bracket-spacing option is that nobody knows exactly why it exists. It was added super early on without much thought. It now serves as an example of the types of options we should avoid. See:

• https://github.com/prettier/prettier/issues/715#issuecomment-281096495
• https://github.com/prettier/prettier/issues/3503#issuecomment-352169372

[lydell]

https://github.com/prettier/prettier/issues/812 is an example of what it took to get the arrow-parens option. This issue almost has the same number of 👍s and comments. The big difference is that arrow-parens is not only about style. It can also be argued that always using parens around the parameters makes it easier to add destructuring, default values, a second parameter and type annotations (all of which require parens). But in the case of space before function paren, it is all about style. And it doesn’t affect readability one way or the other. It’s purely about what your eyes are used to seeing. In other words, adding an option opens up for useless discussions in teams adopting Prettier (“should we enable --space-before-function-paren or not?”) Remember, Prettier is not a kitchen-sink JS formatter. It is _opinionated._ As mentioned in https://prettier.io/docs/en/why-prettier.html:

By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles.

[MysticEarth]

And it doesn’t affect readability one way or the other. It’s purely about what your eyes are used to seeing.

Well, it seems that for a lot of people it actually does affect readability. And isn't Prettier all about that?

"...It removes all original styling* and ensures that all outputted code conforms to a consistent style. (See this blog post)"

[lydell]

Well, it seems that for a lot of people it actually does affect readability. And isn't Prettier all about that?

Could you point us at which comments in this issue suggest that?

[MysticEarth]

The OP states this clearly just like the comment by @justrhysism. Besides that, the steady discussion says a lot as well...

[Aanhane]

I understand the opinion and it's good to be critical about what gets added and what not. I too want a tool that just works without a lot of configuration, I'm totally not interested in setting specific style rules for each and every project, I care about ease of use and consistency more than whether or not spaces or tabs are used for example.

And about this quote:

By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles.

Ironically, prettier actually dragged me into this. The whole reason I came here was because of an error I got that actually blocked me from developing, since prettier conflicted with the standard vue-cli rules.

For me, that's the reason to stop using it. In order to support any vue-cli project, by not using prettier I only have to change my VSCode config once instead of about every vue-cli project I want to start.
I will repeat again: for anybody that came here because you are running a VueCLI project with VSCode and Vetur, it helps to just switch from prettier to the VSCode formatter by editing your settings like so:

"vetur.format.defaultFormatter.js": "vscode-typescript",
"vetur.format.defaultFormatter.html": "js-beautify-html",
"javascript.format.insertSpaceBeforeFunctionParenthesis": true,

@lydell

Could you point us at which comments in this issue suggest that?

I actually said that specifically to you, in https://github.com/prettier/prettier/issues/1139#issuecomment-341964133. From a UX perspective, consistency is a good tool to improve the user's experience, in this case reading and understanding code. Then again; one could argue that adding a setting is just as bad for UX.

I respect your views, and wish you good luck in future development. Saying 'no' to a setting is harder, but should be respected.

[lydell]

Thanks. Re-reading the OP, I realized that there’s essentially two discussions going on:

1. Unnamed functions: function() {} vs function () {} – what the OP seems to be about?
2. Named functions: function foo() {} vs function foo () {} – what some of the comments seem to be about?

So perhaps this issue has lost much of its value. Those things are completely different, and at this point we can’t know what people have been :+1:ing.

Perhaps we should open two new issues (closing this one) and make it super clear which issue is about what.

[lydell]

@Aanhane

The whole reason I came here was because of an error I got that actually blocked me from developing, since prettier conflicted with the standard vue-cli rules.

This is a problem with vue-cli, I’d say. It’ll be a cat and mouse game to add options and workarounds in Prettier to "support" what vue-cli demands. As with ESLint, we recommend disabling stuff that conflicts with Prettier.

Could you point us at which comments in this issue suggest that?

I actually said that specifically to you, in https://github.com/prettier/prettier/issues/1139#issuecomment-341964133.

Sorry, I still don’t understand how the space makes a readability difference? Sorry for being slow to understand.

I respect your views, and wish you good luck in future development.

(Just clarifying that “you” is in plural here; I try to convey the views of the _project,_ not _my_ views. :) )

[Aanhane]

@lydell
I agree. That's why I stopped using prettier, because I don't want to edit any ESLint rules for all my (and other's) vue-cli projects.

You don't have to excuse yourself as the discussion did get a bit vague I think. Referencing the 2 discussions; for me, it's both (ESLint 'always' setting I think?), because you differentiate a function invocation(no space) and a function declaration (space), thus making it easy to read. (see what I did there? ;))

And yes I meant 'you' in plural :).

[justrhysism]

I think the OP was discussing both named and unnamed functions equally. I agree with both the points he raised:

1. It looks more like a function invocation than a declaration.
2. The lack of space after a keyword is odd.

With respect to unnamed functions, I _personally_ am not _too_ fussed, but this is likely because I can't remember the last time I wrote an unnamed function instead of an arrow function. But really it should be consistent for the two - I'm not sure why someone would want one and not the other.

Sorry, I still don’t understand how the space makes a readability difference? Sorry for being slow to understand.

The primary reason _I feel_ this is useful, is for searching and also visually scanning the code; it's immediately clear that function foo () { is a declaration and that foo() is an invocation (as the OP states in his first point).

Granted, the visual cue is minor, but many minor cues add up when trying to reduce cognitive load whilst mentally parsing code. Potentially having to "double take" to check that it is indeed a declaration and not an invocation whilst reading (particularly for new code bases, or code you haven't seen in a while), whilst seemingly pretty minor, is something I have noticed since introducing Prettier.

[austinkelleher]

@lydell Per your comment "It’s purely about what your eyes are used to seeing." I think that is quite a generalization. As @justrhysism mentioned, searching for function definition is exactly the reason why I use space before function paren too. See my comment here: https://github.com/prettier/prettier/issues/1139#issuecomment-316096507

I've heard the argument that editors such as VS Code have better search capabilities out of the box. I don't like that argument because it suggests that Prettier syntax is optimized for people using a feature-rich editor and that everyone working in your code base should be using a feature-rich editor.

[lydell]

@austinkelleher Thanks, that’s a good argument. It’s harder to search for method definitions otherwise. Totally forgot about methods, and only thought about functions :)

[chanlito]

Seriously somebody make a PR for this. Please 😭

[lydell]

@austinkelleher Hmm, can’t you search for [space][space][methodName] (or [tab][methodName] if you use tabs), though? Might even be easier since you don’t need to type the entire method name, just a prefix. (This is similar to the technique of search for ion [functionName] for functions.)

[j-f1]

@lydell

function doThing() {}

class Foo {
  doThing() {}
}

const foo = new Foo()

if (condition) {
  doThing() // this gets found by `  doThing`
}

[austinkelleher]

@lydell My thoughts are summed up by what @j-f1 said. Your method is unhelpful in scenarios where there is already indentation in the code and the ion [functionName] example does not handle classes or function declaration in objects using property shorthands for example:

const obj = {
  fn() {

  }
}

fn() // Searching for `[space][methodName]` finds this as well as the original defintion

As I stated in the original argument, I recognize that searching with a space after function paren is not a "catch all" for searchability, but I've found it very useful is many scenarios.

[srhise]

Can we all agree that the 'Using prettier breaks vue-cli projects' is a much larger issue than arguing about the rule itself? There is a bit too much noise on this. Would like to see vue-cli and prettier work well together is all.

[lydell]

@srhise Why can’t vue-cli add support for opting out of stylistic rules so that it can be used with Prettier? Just like there’s eslint-config-prettier and tslint-config-prettier.

[lydell]

To be completely rational, we should just change to always have a space between the function name and the paren in declarations, since it seems to be objectively better: It allows for poor-mans-go-to-declaration via search, while having no space does not seem to have any advantages. But I guess people would be very upset if we did that :) Oh, humans. (Also, would it be worth the churn for all projects that use Prettier?)

[austinkelleher]

@lydell I completely agree. There is clearly a huge demand for this to be supported as an option. I recognize that there are inherent issues with supporting options and that Prettier intends to be opinionated.

With that being said, I too believe that this should have been the default behavior. As you've stated, it has an actual practical use case (as well has interoperability with one of the most popular JavaScript style guides, Standard). I firmly believe that this should be supported as an option and should be considered in Prettier 2.0 (https://github.com/prettier/prettier/issues/3503). It's very disappointing that it has been constantly considered as impractical.

[srhise]

@lydell It can. It doesn't work out of the box though, which can be a bad experience for developers who are having their first go with vue from something like react where they are using prettier just fine.

[Aanhane]

They give you the following options:

Pick an ESLint preset (Use arrow keys)

> Standard (https://github.com/standard/standard)
  Airbnb (https://github.com/airbnb/javascript)
  none (configure it yourself)

And since standard conflicts with prettier, lot's of people run into problems. I think people want the same thing: just set up linting without having to bother with it's configuration.

[lydell]

Interesting question: Where does the space go when using TypeScript or Flow generics?

function identity<T>(value: T): T {
  return value;
}

[j-f1]

I’d say before:

function identity <T>(value: T): T {
  return value;
}
type Identity = <T>(value: T) => T

// but:
type Identity<T> = (value: T) => T

^{\o/ TS highlighting is back}

because the <T> is one of the parameters to identity, but I don’t really like how it looks.

[suchipi]

Would anyone be offended if I made a PR adding an option for this so that I stop getting notifications about it? (tongue in cheek)

[j-f1]

Seems like a good case for an option. At least until 2.0. :shipit:

[justrhysism]

Haven't considered Typescript generics. Looking at the Typescript docs, and also the C# code I have, there is no space at all (but also no space for method declaration, which _does_ annoy me).

For visual comparison:

Space Before

function identity <T>(value: T): T {
  return value;
}
type Identity = <T>(value: T) => T

// but:
type Identity<T> = (value: T) => T

Space After

function identity<T> (value: T): T {
  return value;
}
type Identity<T> = (value: T) => T

// but:
type Identity = <T>(value: T) => T

(╯°□°）╯︵ ┻━┻

I haven't got a reasoned position on this one 😞

[lydell]

Hmm, it has to be before, right?

function identity <T>(value: T): T {
  return value;
}

Because then you can still search for [function name][space].

[atomiks]

Spaces should go between the function keyword and parens because of names

https://github.com/airbnb/javascript/#functions--signature-spacing

const fn = function () {}

But not for method shorthand etc

const o = {
  fn() {}
}

[azz]

We need to be careful interpreting the 👍s on the OP. I suspect most are asking for space before _anonymous_ function paren, as that is what OP describes. I don't think adding a space before _all_ function parens will be a popular change.

[justrhysism]

@azz

as that is what OP describes

Read it again, it isn't.

The request is for a space before function _declaration_ parens.

[justrhysism]

@atomiks

But not for method shorthand etc

Why not? The whole argument is to determine the difference between _declaration_ and _invocation_.

So, method shorthand should absolutely include a space. It _must_ be consistent, otherwise it's not worth doing at all.

[azz]

@justrhysism Yes it does.

was spacing on anonymous functions.

function foo() {
            ^ no space here
 this.bar = function () {
                    ^ space here
   console.log('baz');
 }
}

When I say all, I mean:

function foo () {
            ^ space here
}

[justrhysism]

@azz

That was the example of _existing_ functionality. An example of _requested_ functionality wasn't provided, but _was_ described.

[azz]

It is the input, and the expected output. The rest of the post describes _anonymous_ functions and issues such as no spaces after keywords.

[justrhysism]

@azz

It is the input, and the expected output.

No, it's an example of the _existing_ behaviour.

For example, prettier converts this:

function foo() {
 this.bar = function () {
   console.log('baz');
 }
}

into this:

function foo() {
 this.bar = function() {
   console.log('baz');
 }
}

The words _"For example, prettier converts this ... into this: ..."_ indicate that the OP is describing the current behaviour. I'm really not sure how to make this any clearer.

[azz]

It is stated _several_ times in OP that the issue is raised for _anonymous_ functions only.

1. One of the things that popped out when running prettier over our codebase was spacing on anonymous functions.

2. For example, prettier converts this:
   code with spaces before function parens _only_ with anonymous function

3. While this pattern is becoming less common for us (we'd probably use an arrow function here now), we still have several cases of this. The lack of space after the function keyword just doesn't read right for me.

4. The lack of space after a keyword is odd.

5. https://github.com/airbnb/javascript#functions--signature-spacing

   // good
   const x = function () {};
                     ^ space here
   const y = function a() {};
                       ^ no space here
   

6. http://eslint.org/docs/rules/space-after-keywords

[sparty02]

OP here.... 😄 @azz is totally right on my intention. I even reference a potential PR diff in where the current code only adds a space after the function keyword in the event that an id exists on that particular AST node. This seems goofy and reflects what I think is the biggest sticking point with this whole style; which is that there should always be a space after a keyword. In this case, it's the function keyword, but I think this rule can be applied to every keyword consistently as a general rule of thumb......hence the "prior art" I linked to, including the eslint rule and airbnb style guide which state it pretty clearly.

By the way, for what it's worth, I also personally prefer _no space_ after a function name. e.g. the style reflected in point 5 in @azz's previous comment.

Lastly, I personally _do not_ necessarily think this should be a configurable option. I originally opened this _just_ before the 1.0 release, hoping that given enough feedback, it would become the default style (space after the function keyword). It would have been interesting to know how much code in the wild uses/used function() vs function (), but those results will at least partially be tainted now by, ironically, usage of prettier.

[justrhysism]

there should always be a space after a keyword

@sparty02 fair enough.

Since you've been fairly absent from the thread, it appears to have run away without your input and the waters muddied. I suspect the vague issue title may have contributed to the confusion. Do you feel that a separate issue should be opened for a space after a function name declaration?

[sparty02]

@justrhysism Yeah, given my clarification, if there are strong feelings about the space after the function name declaration, I think a separate issue would be appropriate to address that.

To be clear, I'm going to change the title of this from space before function paren to space after function keyword

[justrhysism]

Okay, so I've created a separate issue (https://github.com/prettier/prettier/issues/3845) for the discussion on space after function name declaration.

I believe both space after function (or indeed, any) keyword and space after function name declaration should be the default - or, at the very least, configurable.

[atomiks]

@justrhysism

Why not? The whole argument is to determine the difference between declaration and invocation.

So, method shorthand should absolutely include a space. It must be consistent, otherwise it's not worth doing at all.

It's not the same thing.

const fn = function() {}
const fn = functionname() {} // error, no space between keywords is a bad idea

const fn = function () {}
const fn = function name() {} // all good

const o = {
  fn() {} // this is logically equivalent to `function name() {}` (no space between name and parens)
}

[justrhysism]

@atomiks that's not at all what I was saying.

Anyhow, the original title of this issue was _space before function parens_ (since changed for clarification), which I believe is the source of much of the confusion. I'm not going to comment on this issue any further as that discussion should now take place over on #3845.

[lydell]

PSA: I'm moving this issue into #3847 to reset the :+1:s.

3847 is about space in _anonymous_ functions: f = function () {}.

3845 is about space after the name: function f () {}.

To anyone who have voted for this issue: Please vote on the other two issues! Thanks!