New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Space after function keyword in anonymous functions #3847

Open
lydell opened this Issue Jan 31, 2018 · 74 comments

Comments

Projects
None yet
@lydell
Collaborator

lydell commented Jan 31, 2018

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

This comment has been minimized.

allex commented Feb 5, 2018

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

@azz

This comment has been minimized.

Member

azz commented Feb 5, 2018

@alexburner

This comment has been minimized.

alexburner commented Feb 6, 2018

+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

This comment has been minimized.

allex commented Feb 6, 2018

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

This comment has been minimized.

Collaborator

k15a commented Feb 6, 2018

@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

This comment has been minimized.

Member

j-f1 commented Feb 6, 2018

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

This comment has been minimized.

Collaborator

lydell commented Feb 6, 2018

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

This comment has been minimized.

Collaborator

josephfrazier commented Feb 6, 2018

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

@coolemur

This comment was marked as off-topic.

coolemur commented Feb 21, 2018

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

This comment was marked as off-topic.

Member

j-f1 commented Feb 21, 2018

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

@coolemur

This comment was marked as off-topic.

coolemur commented Feb 21, 2018

@j-f1 Yes, I do know this link. But still it doesn鈥檛 help to make developers of custom projects use 鈥減rettier鈥 efficiently. If only 鈥減rettier鈥 developers try to read what their tool users are saying.

Philosophy can have its flaws. Hitler had his philosophy too. That didn鈥檛 go well... And this philosophy of creating rock solid code standard without any flexibility in options is so wrong.

This is just an opinion. Don鈥檛 mind my efficient and flexible ideas. Do not reply trying to convince me, because any reply won鈥檛 fix this issue. Not for me. While creating many projects turning off linters for every project is just one more step that this tool is creating. This forces me not to use prettier in those projects. :(

I bet there are many users who see same problem here. But they just chose to deal with it by either unefficiently tweaking linters or just stop using 鈥減rettier鈥.

@j-f1

This comment was marked as off-topic.

Member

j-f1 commented Feb 21, 2018

Prettier鈥檚 goal is not to be flexible. As the page I linked above says:

By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles.
The more options Prettier has, the further from the above goal it gets. The debates over styles just turn into debates over which Prettier options to use.

As you said above:

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.

If we added a whole bunch of options, you would have to configure them all each time you created a new project.

While creating many projects turning off linters for every project is just one more step that this tool is creating.

You have to enable Prettier for each project, too. Prettier makes this step pretty easy:

$ npm i -D eslint-{config,plugin}-prettier
$ npm i -D --save-exact prettier

then, in your .eslintrc.yml:

extends:
  - plugin:prettier/recommended

That will disable all rules that conflict with Prettier鈥檚 styles, while enabling a rule that gives you a description of what needs to be changed to follow Prettier鈥檚 styles.

@coolemur

This comment was marked as off-topic.

coolemur commented Feb 22, 2018

@j-f1

You have to enable Prettier for each project, too.

Even if I use prettier plugin?

If we added a whole bunch of options, you would have to configure them all each time you created a new project.

Why would I need to configure all of them? If I could configure only the ones i need to ?

@jameshhood

This comment was marked as off-topic.

jameshhood commented Feb 22, 2018

I came here looking to figure out if there was a solution for this but only found a bunch of arguing. Its sad when lint has a flexible standard and a formatter tool cant be just as flexible and down right rude about it. When it boils down to it, every developer should be able to configure their project how ever they like. lint has the developers in mind for this and it seems prettier does not. Thanks but no thanks. I will find another tool backed by developers that care about other developers.

@suchipi suchipi changed the title from Space after function keyword to Space after function keyword in anonymous functions Feb 22, 2018

@coolemur

This comment was marked as off-topic.

coolemur commented Feb 22, 2018

@jameshhood EXACTLY !

@duailibe

This comment was marked as off-topic.

Member

duailibe commented Feb 22, 2018

@jameshhood

Its sad when lint has a flexible standard and a formatter tool cant be just as flexible and down right rude about it

Yes, that's pretty much why we oppose adding options for everything. A lint can be as flexible as you want (it can even let you add your own rules, for that matter) because it will just complain if it finds something that doesn't "comply" with the rules. A formatter though has to format every single piece of code consistently and correctly, and adding options means adding overhead to maintainers: more code, a bigger surface for bugs, tests increase exponentially to check different combination of options, etc.

I don't understand your claim that we don't care about other developers, if that was the case we wouldn't bother doing unpaid work to maintain this tool. And I also didn't find anything rude in this thread, other than your comment.

every developer should be able to configure their project how ever they like

I completely agree with this. Developers have the option of using Prettier or not, and configuring the options Prettier has. That doesn't mean we have the obligation to support every JavaScript style out there. Also, the fact this issue was opened by one of the maintainers (and wasn't yet close) mean we're open for discussion and might be willing to support an option if there's significant demand for it (as we have done in the past).

You are also free to use whatever tools available to have a better developer experience, it's great that we have so many quality tools available, for free! We believe Prettier does a great job in that, and if you disagree, we're always open to talk and maybe meet halfway.

@jameshhood

This comment was marked as off-topic.

jameshhood commented Feb 22, 2018

I understand the dilemma yall would have from an internal design and scope perspective but I think this is what many people are running into with this situation. People are wanting more customization because they like your tool and a lot of people promote it. However, the whole purpose of a lint is to standardize your code to a best practice for your project not the other way around. I personally write a bunch of vue apps so I like to use the eslint standard for vue so it basically does an automated peer review. I dont really expect a formatter to 'hold me to a standard' especially since it doesnt throw errors because something isnt syntactically correct. Best practices and javascript changes on a daily basis, so it would be nice is Prettier was as configurable so the community could share configs and be able to make it as customizable as tools like eslint. I like Prettier, it just cant do what I want it to do so I was left using the built in VS Code formatter. Maybe one day it will :)

@coolemur

This comment was marked as off-topic.

coolemur commented Feb 22, 2018

and might be willing to support an option if there's significant demand for it

You have demand for it.
You even have a case to reproduce a problem (vue initial project with lint ruleset which comes out of the box).

I don't think there is a point for you to try to convince people that we can use your defined and forced rules. Because if they won't fit developers needs - they just won't use your tool. Common sense.

Have a nice day. Bye.

@ztolley

This comment has been minimized.

ztolley commented Jun 23, 2018

I agree with the philosophy published, but:

Whats wrong with the linter being responsible for the enforcement of styles and the formatter responsible for formatting the code automatically to the chosen style standard, be it standard js, airbnb or XO ?

@j-f1

This comment has been minimized.

Member

j-f1 commented Jun 23, 2018

@ztolley It鈥檚 very difficult to make a formatter conform to every possible style that someone could possibly want (that鈥檚 the trap ESLint fell into), so we instead decided to be opinionated and only allow a few different styles to make development easier.

If, however, you want to create a pluggable, configurable formatter that allows people to pick any style they like, I encourage you to do so! It seems that many people would appreciate such a tool and a little competition is always healthy 馃榾

@atomiks

This comment has been minimized.

atomiks commented Jul 2, 2018

So after 5 months and 90%+ agreement, will this be changed?

@coolemur

This comment was marked as off-topic.

coolemur commented Jul 2, 2018

@atomiks 5 months is enough to learn write a clean code without formatter.

@bovas85

This comment has been minimized.

bovas85 commented Aug 17, 2018

Any luck on this to be approved/ reviewed?

@j-f1

This comment has been minimized.

Member

j-f1 commented Aug 17, 2018

Can someone tweet this from @PrettierCode to get more 馃憖 before we make a decision?

@albanx

This comment has been minimized.

albanx commented Aug 17, 2018

I think this is not agains the prettier philosophy, which I like and agree with it. We do not need a custom setting for this, we want just consistency. This can be as a definitive change.

@rattrayalex

This comment has been minimized.

Collaborator

rattrayalex commented Aug 18, 2018

@j-f1 can you DM someone with that power if you feel strongly? Frankly, though, the 馃憤 / 馃憥 numbers here are pretty large and seem sufficiently compelling to me (it's pretty rare for an upvote counter to top 200 IIRC).

Otherwise, this feels like a strong candidate for prettier 2.0 and we might as well opt to mark this as "accepting pull requests".

@g-plane

This comment has been minimized.

g-plane commented Oct 1, 2018

There are 200 upvotes now. Will this feature be implemented?

@Th3S4mur41

This comment has been minimized.

Th3S4mur41 commented Oct 4, 2018

Would be great to have this one changed or at least added as an option.
While I like the fact that prettier is opiniated and doesn't have hundreds of options, when a single rule is subject to this much controversy, chances are high that either the tool has this one wrong or should at least consider provide an option for it.
As mentioned above, 200 upvotes does not happen often and should be an indicator that a change is necessary

@j-f1 j-f1 added this to the 2.0 milestone Oct 4, 2018

@j-f1

This comment has been minimized.

Member

j-f1 commented Oct 4, 2018

Given the upvote-downvote ratio, I鈥檓 wondering if we should add an option or just change the behavior in 2.0.

@evilebottnawi

This comment has been minimized.

Member

evilebottnawi commented Oct 4, 2018

I think better change the behavior.

@lipis

This comment has been minimized.

Member

lipis commented Oct 4, 2018

just change the behavior

@o8e

This comment was marked as off-topic.

o8e commented Oct 4, 2018

Scrolling slowly through 9 months of comments advocating this change. Yet here I am at the bottom, disappointed.

Is this not a no brainer? Prettier is autofixing me and ESLint is telling me it's then wrong. I'm stuck.

@evilebottnawi

This comment was marked as off-topic.

Member

evilebottnawi commented Oct 4, 2018

@o8e disable rule in eslint?

@CinKon

This comment was marked as off-topic.

CinKon commented Oct 4, 2018

I simply set https://eslint.org/docs/rules/space-before-function-paren to 0, since there is no better workaround

@covertbert

This comment was marked as off-topic.

covertbert commented Oct 4, 2018

@o8e disable rule in eslint?

Not really a great suggestion when a lot of the time you can't just change linting rules that affect everyone else on your team

@lydell

This comment was marked as off-topic.

Collaborator

lydell commented Oct 4, 2018

@covertbert We recommend turning off all rules that conflict with Prettier: https://prettier.io/docs/en/eslint.html. If you can't do that, use prettier-eslint or don't use Prettier at all. Trying to adjust Prettier to follow other tools' rules is a constant uphill battle that Prettier isn't going to do.

@o8e No decision in Prettier is a no brainer.

Now, let's keep the issue on topic again.

@j-f1

This comment has been minimized.

Member

j-f1 commented Oct 4, 2018

FYI: there鈥檚 a PR ready to go at #3903.

@hawkrives

This comment has been minimized.

Contributor

hawkrives commented Oct 4, 2018

@j-f1 Just remember that the people who are happy with the current implementation probably won't downvote this issue, because they'll never see it.

@lipis

This comment has been minimized.

Member

lipis commented Oct 4, 2018

and I guess half of these people don't care about this option either way.. there are some good arguments for the space.. let's just add it :) we can also tweet something to see some reactions..

@kirillgroshkov

This comment has been minimized.

kirillgroshkov commented Oct 30, 2018

Please 鉂

@JamiesonRoberts

This comment has been minimized.

JamiesonRoberts commented Nov 6, 2018

I know there has been lots of conversation around this one, and I know the philosophy is to not add functionality warrentlessly (IE once its added its hard to take it away). But I think for the sake of keeping the opinionated side of things it should be an option. That way people who don't care about setting it otherwise can keep the default opinion, and those that have been asking for a long time for some flexibility on this one can modify.

@Makoehle

This comment has been minimized.

Makoehle commented Nov 8, 2018

A quick workaround with VS CODE is to activate standard.autoFixOnSave. Then you hit the save button twice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment