Space after function name in declarations

[justrhysism]

NOTE: This issue is raised due to confusion in #1139.
NOTE: Feel free to use the 👍 and 👎 buttons to indicate your preferences, but please refrain from commenting unless you’ve read every comment and made sure yours says something that has not been said before.

This issue is only about outputting these spaces:

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

function identity <T>(value: T): T {
  //             ^ space here
  return value;
}

class A {
  method () {
    //  ^ space here
  }
}

const obj = {
  method () {
    //  ^ space here
  }
}

(Prettier currently does not put spaces in those positions.)

🗒 NOTE: This issue is not about anonymous functions:

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

Anonymous functions are tracked in #3847!

The key arguments is:
Searchability: You can find any function or method declaration my searching for e.g. method ( or identity <, or even just name[space] (mostly).

It also provides a clear and immediate difference between declaration and invocation.

(There are many existing comments in favour of this style, notably: #1139 (comment) and the majority of the discussion from #1139 (comment) onwards.)

[brianjorden]

This is one of the reasons I've had to step away from adopting Prettier. I would be quite happy with just an optional flag. The original issue talked a lot about configuring and adding in eslint to re-process and alter the output of the code AFTER prettier has a go at it. My understanding from what I read is that was being suggested to "reduce configuration" that people generally needed to do and obviously it is just trading where configuration is being done.

Additionally, many people don't actually use ESLint, so the suggestion is to actually bolt on another entire tool to the build chain. That falls down further when talking about a combination of TypeScript + Vue + Vetur + Single File Components as right now I don't believe there is a working implementation to combine TSLint + Prettier + Vetur.

I currently maintain a fork of Prettier mainly for this reason, but it breaks constantly. An additional challenge comes in with Vetur not currently using the locally installed version of Prettier, but the Prettier VSCode extension doesn't run on .vue files. I've resorted to manually overwriting the installed version of prettier in three node_modules locations every time things get updated (local project, global, and vetur). Needless to say, it breaks a lot.

Many people/companies/projects can't simply change certain aspects of their code spec requirements on a whim. Prettier matches, or is close enough to the vast majority of rules we're using, and obviously the rules in some of the most popular sets of standards used with things like ESLint, except this ONE item. Most other variations can be dealt with through a prettier-ignore comment, but obviously this is extremely wide spread and a major point of contention.

I hope that all those involved will look at and consider the rather large number and volume of voices just asking to incorporate an opt-in ability to handle adding a simple space. The arguments of this being "bike shedding" feel a bit silly to me. The alternatives are to either disable rules within the most popular sets of linting rules OR add an entire extra set of tooling/parsing of every file.

[j-f1]

@brianjorden You might be interested in our hot-off-the-presses docs on why we don’t accept most option requests.

[brianjorden]

I get all of that, but on that same logic, why would the core and ONLY option of Prettier then violate the extremely popular much older linting/coding standards on this exact issue? I totally get doing things in a very opinionated way, but the standard and airbnb rules have been downloaded millions of times per month since long before Prettier existed. Honestly, I personally don't even like a lot of those "out of the box" rules. The oddity to me is that this is the ONE item that seems to violate the prior defacto-standard sets of rules that a lot of people have been using for a long time. I may be wrong in my overall understanding, but if the concept is to avoid the "holy wars" and "bike shedding" cliche concepts, why is this one rule different than some of the popular standards?

[lydell]

First off, please note that we're not stubbornly saying no to this. This issue is open, and is now part of the process for adding options. That process isn't formally written down (like ESLint's) but it has kind of started to grow out of itself.

We're now waiting for that 👍 counter to increase. Give it some time.

The original issue talked a lot about configuring and adding in eslint to re-process and alter the output of the code AFTER prettier has a go at it. My understanding from what I read is that was being suggested to "reduce configuration" that people generally needed to do and obviously it is just trading where configuration is being done.

Additionally, many people don't actually use ESLint, so the suggestion is to actually bolt on another entire tool to the build chain.

The suggestion is generally to let it go and just use Prettier. But if you can't do that, there's always the option of using prettier-eslint. Or not using Prettier at all. Or wait, and see if people change their minds.

except this ONE item

Everyone says that in every issue :) "This is the ONLY thing preventing us from using Prettier." We'd have a lot of fix-somebody's-only-problem options at this point if that was a convincing argument :)

Many people/companies/projects can't simply change certain aspects of their code spec requirements on a whim.

This might be a silly, but this is how I imagine that scene playing out:

employee: I've found a tool that could reduce the time we spend on formatting code and fixing lint issues. Can we give it a try?
boss: Does it comply with our style guide?
employee: Yes! Except one rule.
boss: Sorry, our arbitrary choices are more important than the productivity of our employees.
employee: Can we at least give it a try to evaluate it?
boss: No! Those spaces are part of the company's core values.

I mean if Prettier complies with all of your style guide except one item, isn't that a huge success? If you can't even change one item of your style guide – that's even about just a single space – I'm not sure if you should use Prettier at all. Every new Prettier version runs the risk of inroducing some minor conflict with your style guide.

Honestly, I personally don't even like a lot of those "out of the box" rules. The oddity to me is that this is the ONE item that seems to violate the prior defacto-standard sets of rules that a lot of people have been using for a long time. ... why is this one rule different than some of the popular standards?

Because it's not that easy. In fact, I've very rarely worked on a code base that use the space-after-function-name rule. Hadn't even heard of it before I found standard. Remember, when James Long first implemented the core printing he had a lot of decisions to make. Perhaps he hadn't worked on many code bases with space-after-function-name either and didn't think about it. Or he just needed to choose something to be able to move on, so Prettier could be released and not stuck in decision making forever. We try hard to choose non-controversial style decisions (for markdown we even used bigquery to gather stats), but we also have to consider the churn of making changes that affect all existing Prettier users. So sometimes we're stuck with decisions made in the past, and it takes time to find the best way forward. So this is not about the Prettier authors trying to impose their style preferences to the world. It's about historic decisions, which plague all software and specifications.

It is also not a clear "defacto standard". ljharb from airbnb says (#3503 (comment)):

the most common and consistent standard for function keyword spacing in the ecosystem is "function keyword", "space", "optional name", "argument list".

I hope that all those involved will look at and consider the rather large number and volume of voices

We certainly will! Consider the fact that the original issue was split and re-opened through this one a good sign. Now, we need to let things settle a little. Give it a think-through. Gather some more 👍s and comments.

(Or perhaps somebody makes a PR that is merged next week. Who knows.)

[bakkot]

Neither AirBnB nor Google recommend this style. It is not the style used by jquery, react, preact, bootstrap, babel, TypeScript, flow, express, angular, v8, spidermonkey, RxJS, lodash, istanbul, node, ember, d3, socket.io, qunit, jest, ava, jasmine, webpack, polymer, chartjs, gulp, bluebird, ramda, esprima, yarn, handlebars, immutable, uglifyjs, grunt, jsdom, glamorous, koa, eslint, or indeed prettier itself.

Not to say prettier's style is universal; there are exceptions: browserify, moment (sometimes), mocha, rollup, vue, npm. But these are much, much rarer.

I was going to say something about how the style suggested in this issue wasn't the de facto standard in the ecosystem, but now that I've gone and looked, I'm going to make a stronger claim:

There is in fact an overwhelming de facto standard in the ecosystem, and it is what prettier already does.

I don't think we should worry too much about votes. The ecosystem is far larger than this issue tracker could possibly reach. This seems like a place prettier should stick to its guns.

Edit, 2018-05-11: both mocha and rollup have adopted prettier and the no-space style; I've struck them out from the list of non-examples.

[brianjorden]

First off, I was completely wrong on the AirBnB thing (and just wasn't sure on the Google suggestions). Second, although I don't know that I should go back and edit my prior comments, they did likely come off way too harsh/judgy/stubborn on my part, and sorry for that.

As to the usage and frequency in the ecosystem, there are some fairly sizable projects/groups that rely on standard and therefore likely are following this rule. (I had put together a little list before I saw bakkot's above.) Things like NPM, GitHub, Electron, Atom, Moment, Vue, Zeit, MongoDB, Zendesk, Mocha, Karma, WS, and https://raw.githubusercontent.com/standard/standard-packages/master/all.json

I'll admit, by no means a consensus or majority, but some non-trivial sized groups involved there. Also, the idea of "how that conversation would go" thing is amusing, but doesn't quite fly in the consulting world when talking about deliverables, contracts that call for code spec conformance, and a multi-layered IT department of even a moderately sized corporation. The suggestion of "just use eslint" doesn't quite work when I had explained that isn't actually an option (TypeScript + Vue + Vetur).

You also mentioned that this isn't just people being stubborn, and although of course the maintainers/original creator has every right to be stubborn, it does feel like there is a bit of that honestly. Couple small examples:

• Space after function keyword - MOVED to #3847! #1139 (comment)
• Prettier 2.0 (old) #3503 (comment)

In reading through some of the 2.0 comments, it has become pretty clear I need to back off and find a new approach though. I know it got retracted a bit, but even comments about possibly removing TypeScript support came up over there. I do like and appreciate what this group has contributed and look to be contributing in the future. I'd love to actually do the PR to add the config option for this, but that proposal got completely shot down in the other threads. Just seems like sometimes groups (not just this one) can be a bit uninviting to new contributors or even discussion about a possible contribution.

My only point in trying to put so much effort into showing that there aren't realistic options to "just use another tool as well" and that a decent number of people/groups/projects would benefit from this, is that I think the "bike shedding, closing issue" thing can be a bit misused at times. To me and I think to many others, it is more "my bike has 3 wheels and can't fit through the door, could we make the door slightly wider?" and the response is "most bikes fit, go away".

[lydell]

@brianjorden Don't worry, this issue is open and isn't going anywhere! Just be patient :) (The original issue was closed when Prettier was just a couple of months old and we didn't know how to handle Prettier's popularity growth yet.)

even comments about possibly removing TypeScript support came up over there [in the 2.0 discussion]

You're misunderstanding – TypeScript support will never be removed. If anything it could be moved outside the Prettier core, but I doubt that.

[j-f1]

As one of the people advocating the removal of the TypeScript parser, I’d like to clarify: Babylon 7, our JS parser, has support for TypeScript. However, we currently use TypeScript’s parser to parse TypeScript. I was suggesting moving the code that uses TypeScript’s parser to an external plugin, then use Babylon to parse the TypeScript, decreasing the bundle size.

[bakkot]

Things like NPM, GitHub, Electron, Atom, Moment, Vue, Zeit, MongoDB, Zendesk, Mocha, Karma, WS, and https://raw.githubusercontent.com/standard/standard-packages/master/all.json

Interestingly enough, GitHub, MongoDB, and Zeit are already using prettier (elsewhere?). Mocha has been discussing adopting it, and a couple of the owners specifically mention not caring about this particular issue. So I don't think the lack of an option here is all that much of a barrier in general, even though it might be on some specific projects.

[TrySound]

Btw rollup is also gonna adopt prettier, so its own code style will be eliminated
rollup/rollup#1896

[justrhysism]

a couple of the owners specifically mention not caring about this particular issue

Those that don't care, by definition, wouldn't care if it was implemented.

[j-f1]

Those that don't care, by definition, wouldn't care if it was implemented.

Apathy isn’t a good reason to add a new feature :)

[justrhysism]

Apathy isn’t a good reason to add a new feature :)

Agreed. With respect to adding weight to an argument, apathy is neither for, nor against an argument - which is the point I was trying to make.

[ahimta]

I need to have spaces after function because this conflicts with Standard and I have to run a lint script manually that runs Prettier then Standard. Because I can't have save-on-format in my editor to do the same thing.

I don't disagree with Prettier not having spaces after function, it's just very inconvenient for me.

Thanks and keep up the good work!

[j-f1]

@ahimta Have you seen prettier-standard?

[duailibe]

Agreed. With respect to adding weight to an argument, apathy is neither for, nor against an argument - which is the point I was trying to make.

In this case, apathy is an argument against implementing this.. if most people don't care about it, there's no reason for us to carry the burden of supporting in the future.

[ahimta]

@j-f1 what I really want is editor support. Otherwise, I could easily use git hooks or watch scripts -_-.
If Prettier decides to add an option for a space after function I may have enough motivation to implement it myself :).

[lydell]

@ahimta It sounds like you have confused this issue with #3847.

[ahimta]

@lydell sorry I mean both (all function declarations). Since this is the one thing that Standard doesn't allow.

[lydell]

sorry I mean both (all function declarations).

Whitespace is mandatory between the function keyword and the function name. This issue is not about a space after function. It is about a space after the function name. See the OP.

[ahimta]

@lydell I mean exactly these two cases:

1. function () { }
2. function f () { }

[josefaidt]

I think it's important to understand is Prettier's ultimate purpose to be a code formatter, or a specific code style (like Standard.js, AirBnB, etc)?

[bakkot]

"Prettier is an opinionated code formatter."

[j-f1]

So the answer is “kinda both.”

[thevirajshelke]

I wanted to use standardJS rules strictly.

Then you shouldn't use Prettier. The two projects use slightly different code style.

Yeah, I understood this. So now I am ignoring all the JS files & other files like (HTML, CSS, etc.) are being formatted by Prettier. I don't want to discard Prettier completely because I liked the project :)
You guys are doing a good job 👍 My best wishes :)

[FredericLatour]

I had no idea before getting frustrated with Nuxt/vue and prettier formatting option and reading this discussion that Prettier was not a tool only but was also advocating a specific style.

I don't understand why Vue is still proposing Prettier support in the tooling configuration chain while Prettier is not able to comply with their own formatting/linting rules. From this discussion I get that Prettier is promoting a style guide that is in incompatible with Vue own style guide. Considering the strong opinion of Prettier devs on this matter, Prettier support should be removed completely (nothing would prevent to use it by installing the necessary parts though). It would clarify things up and will prevent people from wasting time.

On a more general standpoint, I would be all for some kind of formatting standard from a committee for javascript / typescript but in the absence of such a standard, I would rather follow framework's style guide rather than Prettier style guide. That's a practical matter besides any strong preference which I don't really have.

Of course, Prettier maintainers can do whatever they want but it sounds somewhat counter productive. Prettier devs should differentiate the 'style guide" they are promoting (Prettier Standard) and the tool itself. If prettier is supposed to be a tool dedicated to a specific Standard (Prettier's one) why not removing all configuration options altogether ? Either it's too flexible or not enough.

Time to find a more agnostic tool I guess.

[lydell]

@FredericLatour I think you should talk to the Vue maintainers about removing Prettier from their tooling. Mentioning it here won't help.

See also our option philosophy – I think it should answer most of your questions.

[FredericLatour]

@lydell I mentioned it here because I wanted to expose my point of view and possibly being pointed out something I'm missing. Seems like you are implicitly admitting that it does not make sense that Vue offers Prettier as a configuration option when it conflicts with it's recommended settings/ (which are configured by default by the way), unless they change their style guide. There's no use in making people frustrating looking around and ending in being even more frustrated. I will therefore open an issue on vue's github.

Indeed, your option philosophy is clear enough. That said, I would make two comments:

1. Many people are adopting prettier because it's configured or available in the configuration options of their framework. They just don't really care about the details. I don't mean to be provocative but there are already so many things to take care that going into the details of the tool or plugin that is supposed to formal the code properly is not really high priority. It is therefore easy to miss that Prettier is more of a "style guide" (supported by a tool) than a generic tool.
2. Your reasoning on this philosophy page makes sense. However, when a framework with 146 000 stars have a somewhat inconsistent approach by promoting Prettier to some extent and adopting an incompatible style guideline, you could possibly get in touch with them to clarify things up.

[lydell]

@FredericLatour Could you please link to the vue issue you opened when you've done so? I think it could be of interest to others following this thread.

[FredericLatour]

@lydell I have to do a bit of homework here because the problems I faced are on Nuxt.js (which is based on Vue.js). Most probably, I will encounter the same problem (I can read many people are complaining about inconsistency between prettier and vue rules) with Vue.js but I have to check first by creating a simple project.
That being said, I did some research and it doesn't seem to really exist a formatting tool like Prettier (especially when editor integration is concerned) that can take care of most languages used in the web development area. Every alternative seems to be lacking in a way or another.

Because, I doubt that people will get to accept one formatting standard, there is a real need for an agnostic formatting tool à la Prettier (that works nicely with editors) so that people can apply either Prettier, Standard or Airbnb style (hopefully the list won't expand). And honestly, the difference is so tiny between those standards that it won't really miss the goal of having a consistent code base that feels familiar.

With such a tool, you'll end up with with Agnostic Prettier, and ESlint, Rules Plugins and you are done. Instead of the current messy situation where people are trying to make things work all together with mixed success.

On a personal standpoint, both Prettier and Standard style guide are fine. I may have some aesthetic preferences on some specific point, however, I'm more than ready to adopt another rule for consistency.

On another note, when possible important changes are concerned, I find the "+1" approach quite limited. Having 200 (+1) versus 30 000 stars !!
You should opt-in people that are willing to vote when important matters are concerned and then send them a request for voting when necessary. You may not decide to follow the vote but at least you would have a more representative situation.

[lydell]

@FredericLatour Sorry, I tl;dr-ed on your comment. Let me know if there was something you wanted me to respond to.

[FredericLatour]

@lydell no tx (short enough?)

[glen-84]

Hey folks, I'm working on a PR that would add a spaceBeforeFunctionParen option so it's time to figure out what color to paint the shed! :)

If an option is added, it should be named similar to spaceAfterFunctionName, and not spaceBeforeFunctionParen, as the latter would conflict with the topic of #3847.

[SashaSirotkin]

A bit late to the party here. I just saw always add a space after the function keyword item in the changelog for the 2.0.0 release and my first reaction was "huh, that's weird". The function space change was a significant unconventional styling change and there was no explanation of its utility in the blog post. Decided to rummage through the repo issues to get more context.

Most other decisions that Prettier makes seem to represent the most wildly accepted practice at the time. However, the changes regarding function name () (and function ()) seem to be contradictory to that which is highlighted by this comment by @brianjorden.

As Prettier gains more adoption and becomes defacto code formatter it steadily gains a kingmaker position for the what is "the most widely accepted practice". That is a lot of responsibility! Prettier is an opinionated code formatter and it would be too much to explain every decision, but up to this point the opinions haven't been surprising (even the ones I disagree with). Now, it looks like that is beginning to change and this puts a larger responsibility to explain their decisions in a more publicly consumable format than 100+ comment github issues.

Finally, the following statement by @bakkot gave me significant pause:

There is a loud minority of people for whom this is not their preferred style, and those are of course the people who are the most active in this issue thread.

As it considers the current common coding convention to be the loud minority when in fact it is the silent majority given the current state of the internet per @brianjorden's comment.

EDIT: I shouldn't scan the thread at 3am! Sorry @bakkot!

TL;DR: As Prettier becomes the defacto code formatting standard it will transition from "this is a curated set of formatting best practices" to being the best practice. This puts more of an educational responsibility on the maintainers to explain and justify decisions in a more curated way than just github issues (i.e. on the website blog). Otherwise it can reduce trust in the project.

[bakkot]

@SashaSirotkin

However, the changes regarding function name ()

I'm not sure what changes you're referring to. Prettier has not changed the style it uses for named functions.

Finally, the following statement by @bakkot gave me significant pause:

There is a loud minority of people for whom this is not their preferred style, and those are of course the people who are the most active in this issue thread.

As it considers the current common coding convention to be the loud minority when in fact it is the silent majority given the current state of the internet per @brianjorden's comment.

Did you see my survey of the styles used in major JavaScript projects above? I feel it rather firmly justifies my belief that the style asked for in this issue is not in the majority, silent or otherwise. If you disagree, on what grounds?

---

But I think we might be talking past each other, since the focus of this issue is the formatting of named functions, which has not changed. It was only the style for anonymous functions (#3847) which changed (from function() to function ()).

[SashaSirotkin]

@bakkot Sorry! I misread your statement! I will update my post accordingly.

[franleplant]

Im really glad I dont have to have these discussions inside my company or projects anymore, thank you prettier for existing ando sorry to fill your issues with bikesheding

…

On Sat, 28 Mar 2020 at 03:55 Sasha Sirotkin ***@***.***> wrote: @bakkot <https://github.com/bakkot> Sorry! I misread your statement! I will update my post accordingly. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3845 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOEIJ7UCYIMLYWP5XPTDCTRJWNN7ANCNFSM4EONSNXQ> .

[thorn0]

It's clear by now this isn't going to change.