Prettier: Feature Request: breakBeforeElse

[vishnevskiy]

I know the goal of prettier is to standardize on a style, but it is also difficult since this did not come out at the same time as the language.

Our team uses the exact same style as prettier except placement for else statements. It is effectively blocking us from adopting this awesome library.

We prefer break before else to allow for cleaner comments.

// This does something
if (a) {
}
// This does something else if
else if {

}
// This does something else
else {

}

Which is nicer than.

// This does something
if (a) {

// This does something else if
} else if {

// This does something else
} else {

}

However this is preference and would be awesome if this was added as an option to prettier.

@vjeux showed how easy it is to do https://github.com/prettier/prettier/pull/837 and apparently @jlongster likes it :) https://twitter.com/jlongster/status/834407714965057540

[vjeux]

Related discussion https://github.com/prettier/prettier/issues/807

[SimenB]

Is this the discussion issue mentioned in #837?

If so, here goes: I would prefer it to remain like it is, because it's AFAIK the most prevalent style (it's at least 1TBS), and the default in airbnb, google and jquery code styles (to name a few).

For a real argument besides popularity, I like that related block are connected together. Having else (if) being on the same line as the closing brace of the preceding if, makes it very clear at a glance that the else (if) block is connected to it, instead of being it's own separate entity.
Possible bonus: IDEs providing collapsing of blocks can then naturally collapse the whole if-chain, which doesn't really make sense if there's a newline between.

However, I wouldn't be unhappy if an exception was made for a comment, so this was valid:

if (allIsWell) {
  // Live happily ever after
}
// We only get here Ragnarok is upon us
else {
  // Put on your swimsuits
}

[Kerrick]

This feels like one of those "I can't adopt prettier unless" options that was mentioned in the 1.0 release blog post. I'm in the die-hard camp of else being on its own line for the sake of our eyes scanning down a single column to see if there _is_ an else block. I can't really see myself adopting prettier without a breakBeforeElse option.

[jlongster]

I do think that this style is better, but our current style is by far the move prevalent style. As there is a clear majority, and this is an issue that only affects a smaller percentage of code (not like semicolons, etc) I don't think we should have a configuration option for it. If we opened up something at this level, there are many other things we should add config options for as well. But we need to make some choices and this one, in my opinions, falls in that camp.

[rhengles]

@Kerrick As mentioned on #837, breakBeforeElse is supported on arijs/prettier-miscellaneous, and its goal is to support minor features/extra options not picked by Prettier.

[vjeux]

We are past 1.0 and are not going to do any major formatting changes to prettier or add more options. Feel free to use prettier-miscellaneous if you do want it.

[j-f1]

See also #4986.

[JoshMcCullough]

I guess I don't understand why the maintainers here are so against giving us the _option_ to put else and else if on a new line. But it sounds like nothing will be done?

Meanwhile my dumb brain will continue to make me move else/else-if to its own line only for that work to be undone when I commit my changes.

[duailibe]

@JoshMcCullough We won't add options unless extremely necessary. Please read https://prettier.io/docs/en/option-philosophy.html

[j-f1]

Also, we now support the formatting in the issue, if you put a comment between } and else:

Prettier 1.16.1
Playground link

--parser babylon

Input:

// This does something
if (a) {
}
// This does something else if
else if (b) {

}
// This does something else
else {

}

Output:

// This does something
if (a) {
}
// This does something else if
else if (b) {
}
// This does something else
else {
}

[JoshMcCullough]

Okay, fair enough. I misunderstood what prettier was intended to be used for. I'm was thinking something more like editor config. Thanks.

PS: IMO the prettier team went the wrong way on the if/else-if/else choice. ;-)

[nunovieira]

Is this still under discussion despite being closed? I hope so.
This should be an option. Adding a comment to break } and else is a crappy workaround.

[phaux]

I just changed few lines to add this feature in #6017. Can we discuss it again?

[lydell]

We could just as well keep the issue open, like we do with several other discussions/option requests.

[jhildenbiddle]

Adding another vote for breakBeforeElse.

I've read the Option Philosophy and appreciate the goals. I just happen to be in the "will not adopt without this option" camp and believe this option should be considered.

I noticed the following on the Option Philosophy page:

--arrow-parens was added after – at the time – huge demand. Prettier has to strike a balance between ideal goals and listening to the community.

The linked issue has 62 up votes and 12 down votes. The --jsx-single-quote option was also added "after great demand". This issue currently has 40 up votes and 0 down votes. Is there a threshold that needs to be crossed before a new option is considered?

[alexander-akait]

Why you need this option? Please show to us real code with real problems

[jhildenbiddle]

@evilebottnawi --

Sure. Just imagine the same code and problems used to justify including options like --use-tabs and --tab-width.

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

Makes sense. You've got to pick your battles. So why not be "opinionated" about two of the most—if not _the_ two most—frequently debated style choices among development teams? Prettier could declare "spaces not tabs, two spaces not four" in an attempt to "stop all the on-going debates over styles", but doing so would mean a lot of people would never adopt prettier so an exception was made. Similarly, I listed two options above that were added due to "huge demand" and "great demand", so there is a history of adding options to prettier when interest is high enough.

My intention isn't to be argumentative. As I said, I appreciate the goals of Prettier and understand that new options must be very carefully considered. The question I posed seems fair given the history of demand driving the introduction of new options: Is there a threshold that needs to be crossed before a new option is considered? Since that's a pretty open-ended question, let me pose a different one: if--arrow-parens was added due to "huge demand" with 62 up votes, will this option be considered if this issue meets or exceeds the same number of up votes?

Prettier has to strike a balance between ideal goals and listening to the community.

Yep. 😄

[alexander-akait]

Is there a threshold that needs to be crossed before a new option is considered?

Yes, real code examples and real problems. Voting is just clicking on emoji. Many developers don't know what they want and don't know why do they need. Many of them say "In our company we love this style", but prettier more them somebody company. Therefore, we do not add options because someone else wanted something.

I'm pretty sure that if i will open issue about adding space after ! in if (! myVar) {} I will get same votes as here. So votes it is meta. It is also worth saying that many developers like to argue, but when the time comes to implementation they disappear. Words is simple, code is difficult.

The fastest and easiest way to fix, change or add something in prettier is show code with real problems, even a vote is not needed.

P.S.

I already get :-1: on prev post (10 min) :smile: Seriously? What is wrong to provide examples?

[alexander-akait]

if --arrow-parens was added due to "huge demand" with 62 up votes, will this option be considered if this issue meets or exceeds the same number of up votes?

Because using:

something => something * something

and

(something, other) => something * other

is inconsistently and it is real problem. And i think we remove this option in 2 version in favor to alway use ().

[jhildenbiddle]

Guess what else is inconsistent?

if (a) {

}
// Comment
else if (b) {

} else {

}

And what “real problem” does the lack of parens in arrow functions cause? I’m going to have insist on real code demonstrating a real problem here, @evilebottnawi. ;)

[j-f1]

@jhildenbiddle How often does that kind of code come up though?

[jhildenbiddle]

For me, fairly often because I tend to summarize behavior above the if or else statement when the content of the block is lengthy or complex. I know I could just add a comment before every else block to see the results I’m looking for, but then I’m manually formatting code so prettier can automatically format my code.

The same inconsistency is tough to ignore when an if/else block with comments (as described above) is near an if/else block without comments:

// Comment...
if (a) {

} 
// Comment...
else {

}

if (b) {

} else {

}

Hope this provides better context for the request.

[lydell]

We're in the process of updating the option philosophy page with everything we've learned since the last revision, so don't spend too much time quoting from it and making arguments based on it.

[nunovieira]

Here are some examples why this option could make for better code:

if (something) {
  some statements
  some long statement
}
else if (something_else) {
  some other statements
  another long statement
}
else {
  the end
}

try {
  dangerous code
}
catch (error) {
  phew, saved it
}

do {
  some statements
  some long statement
}
while (something)

Without this option, the generated code is compact but less readable.

[JoshMcCullough]

@evilebottnawi looks like we probably can't show you a good example because your mind is already made up. Your claim that parens around single lambda parameters "is real problem" IMO is not. A lambda is perfectly -- and probably more -- readable without the parens around a single param.

Whereas else-on-same-line does cause issues e.g. when you are commenting each if block to indicate/clarify the clause, before the if statement (as already demonstrated multiple times in this thread). Else on the same line makes me cringe every time I write some beautiful code just to have prettier un-pretty it (in this case). I agree with most/all of the other things prettier does, this one I can't agree with.

I understand the aversion to add new/more options, but seriously ... Just Do It™ (Nike).

[alexander-akait]

your mind is already made up

Who says this? I just listen community. Any innovation in prettier is always a dispute. What is the problem to solve this with eslint?

I just want to hear all the possible problems to see if we need it or not.

[jhildenbiddle]

Regarding the consistency issue:

js // Comment if (a) { } // Comment else if (b) { } else { }

Output:

js // Comment if (a) { } // Comment else if (b) { } else { }

Demo

The current behavior introduces a new debate for teams to have over how to write comments for these blocks since devs can individually control Prettier's output based on how they write their comments. This not only exacerbates the consistency and debate issues Prettier aims to solve, but it can have the unintended side effect of influencing how devs provide assistance through comments in their code (too much or too little, to force a specific style).

Consider the debate:

• Should we just be okay with Prettier's mix of 1TBS and stroustrup styles?
• Should we never comment above else statements for consistent 1TBS style?
• Should we always comment above else statements to force consistent stroustrup style?

• Should we allow mixing of styles, but never in the same if/else block?

  // YES (1TBS)
  if (a) {
  } else {
  }
  
  // YES (stroustrup)
  if (a) {
  }
  // Important comment
  else if (b) {
  }
  // Unimportant comment added for styling
  else {
  }
  
  // NO (mixed)
  if (a) {
  }
  // Comment
  else if (b) {
  } else { 
  }
  

Providing a breakBeforeElse option addresses these issues by ensuring if/else statements and their surrounding comments are always formatted the same way regardless of how comments are authored. It's actually the only way to enforce a single, consistent style for if/else blocks (assuming you don't consider the current behavior "consistently" mixed) which is one reason people (like myself) prefer it.

As others have mentioned, the option also produces better diffs and addresses code-folding issues with some IDEs. This comment is lengthy enough already so I won't dive into those.

Finally, it's been mentioned before (here, here), but these same arguments apply to try/catch, do/while, etc. blocks as well. Just thought I'd put that out there to make some people's head explode. 😩 💣

[alexander-akait]

For me it is bug:

// Comment
if (a) {
}
// Comment
else if (b) {
} else {
}

If comments present we should print:

// Comment
if (a) {
}
// Comment
else if (b) {
} 
else {
}

[alexander-akait]

/cc @prettier/core

[suchipi]

I don't think we need to change this

[alexander-akait]

@suchipi why? with comments it is looks very ugly, when i write parsers/lexers/etc i always if comments between if/esle if/else and difference styles branches look very ugly

[suchipi]

I don't like that adding or removing a comment could change the diff elsewhere in the file. It could create merge conflicts that would be frustrating for people.

[JoshMcCullough]

@suchipi Comments shouldn't change the position of the else statement. That's why we're asking for a new option to _always_ put else on a new line. That way it's there regardless of any preceding comment.

[jhildenbiddle]

I agree with @suchipi. @JoshMcCullough is also correct.

To clarify, I believe @suchipi is referring to @evilebottnawi's suggestion of applying breakBeforeElse automatically to individual if/else if/else statements when comments require doing so to enforce a consistent style within that statement (correct me if I have this wrong, @evilebottnawi). The issue with this approach for me—in addition to the diff issue @suchipi mentioned—is that styles will still be inconsistent throughout the codebase:

if (a) {
}
// Comment
else if (b) {
}
else {
}

if (x) {
} else if (y) {
} else {
}

The option being requested by myself and others (this thread, #837, #2573, #3084, #3537, #3832, #4610, #4986, #6017, and likely others I'm missing) is to always apply breakBeforeElse (as @JoshMcCullough pointed out).

I'd also propose that anyone concerned about better diffs and merging should be in favor of breakBeforeElse, not against it.

For those that suggest anyone who cares about this issue simply adopt prettier-miscellaneous or eslint + brace-style, consider that the former hasn't been updated in over two years and the latter means formatting code twice and dealing with potential conflicts as a result (e.g. format-on-save in your editor).

[alexander-akait]

Yes, always break if you have comments

[waitingsong]

@JoshMcCullough

I guess I don't understand why the maintainers here are so against giving us the _option_ to put else and else if on a new line. But it sounds like nothing will be done?

Meanwhile my dumb brain will continue to make me move else/else-if to its own line only for that work to be undone when I commit my changes.

I think the situation is we want to customize the style standard throught Prettier, however the team want to formulate the standard they wish on.
Maybe eslit is enougth and Microsoft will use eslint instead of tslint

[dpipchenko]

So what is a valid workaround to get "line breaks before else" working in an IDE? I am specifically interested in WebStorm/PyCharm/PHPStorm/... family.

I tried adding "brace-style" : ["error", "stroustrup"] into ESLint rules as suggested above - this enables a "never valid" mode as Prettier and ESLint rule start conflicting as shown on the screenshots below:

I don't think installing a separate WebStorm plugin for Prettier can help as obviously it is expected to always show the warning from Prettier, too. I agree with @jhildenbiddle that prettier-miscellaneous is not an option as well, as 2 years without updates is a lot - I don't want to lose all the fixes you guys implement at Prettier.

We'd be happy to use Prettier, I love the philosophy behind the tool ("ensures that all outputted code conforms to a consistent style") but frankly the mentioned example looks a major inconsistency to me:

if (a) {
}
// Comment
else if (b) {
}
else {
}

if (x) {
} else if (y) {
} else {
}

Which is a pity, as I gave Prettier a quick try and all the rest looked excellent so far.

So, is there any workaround to fix that inconsistency?

[lydell]

@dpipchenko We recommend turning off all ESLint rules that conflict with Prettier: https://prettier.io/docs/en/next/integrating-with-linters.html#eslint

Alternatively, you could try prettier-eslint.

[dpipchenko]

@lydell I have seen this recommendation. I added the ESLint rule purely to implement the "line break before else" requirement with ESLint as suggested by @evilebottnawi (plus some other folks):

your mind is already made up

Who says this? I just listen community. Any innovation in prettier is always a dispute. What is the problem to solve this with eslint?

Can you be more specific on how your links should help me to add "line break before else"? (As far as I see they don't describe overriding Prettier behavior with ESLint etc.)

[makingglitches]

Jesus I never heard so many people defending a terrible f-ing format style.
newline makes it easier to read instead of making it look like alien code that the brain doesnt parse.
thats why.
levvying another vote for, again.

[jhildenbiddle]

The question I asked here and here remains unanswered:

Is there a threshold that needs to be crossed before a new option is considered?

Seems like a reasonable question, no?

If no, say so. If yes, explain. If unsure, state that and consider being a little less certain and contradictory while reviewing the issues this feature request would address as outlined in this thread and many others. Otherwise, why keep this thread open except to maintain a meaningless void for folks to yell into?

[phaux]

If adding an option is such a big problem, how about making the Stroustrup style the default? It wouldn't be a drastic change anyways. It would only affect else, catch and finally.

I'm gonna sum up all the pros of Stroustrup style again:

• It's one of the standard styles besides 1TBS and Allman
• It's better for line-oriented operations and commit diffs
• Easier to scan visually, because the keywords line up

[jhildenbiddle]

@phaux --

I don't think setting a new style as the default style is the best option because doing so will create a tsunami of diffs following a prettier update. Hence the option. Aside from that, I get the impression that the maintainers are hardline 1TBS advocates. Preferences don't matter here... unless they do. 😉

[lydell]

The question I asked here and here remains unanswered:

Is there a threshold that needs to be crossed before a new option is considered?

The two previous comments you link to are quoting parts of the Option philosophy, showing how another option was added after so-and-so many "votes". We've since realized that our handling of options has been flawed, and we've revised the Option philosophy. Go read it!

So the answer to the question on whether there is a threshold is – no, there isn't and it's complicated.

why keep this thread open except to maintain a meaningless void for folks to yell into?

We don't want people to yell. That's just annoying for everyone. But we've learned that being able to :+1: or comment on an _open_ issue is much more satisfying for people. If we close the issue somebody will just open a new one – that's already happened several times ("I know issue X was closed, but I'm opening this one to ...").

I get the impression that the maintainers are hardline 1TBS advocates

That's not my impression. My impression is more that the maintainers become less and less opinionated about code style overall.

Personally I wouldn't mind the Stroustrup style – even though I've never used it myself ever before! I think it makes sense. But the Option philosophy kind of shows how impossibly complicated changes/options to Prettier have become.

The Prettier issue tracker naturally attracts and concentrates code style discussions. They've been moved from basically everywhere to here. I think this is a big factor to the maintainer burnout I've seen lately. For the time being I think time would be better spent fixing bugs and making some long-awaited breaking changes, such as not formatting html`` and suchlike by default.

[jhildenbiddle]

@lydell --

Fair enough. The new Option philosophy does a good job of summarizing the issues. Prettier won't add options. Life will go on.

Thanks for the post. It's definitely easier to digest than previous explanations.

[makingglitches]

Seems they did answer it, by dodging around the need for an option that actually beautifies code to make it readable instead of hiding an 'else' in clutter lol

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, August 17, 2019 4:11 PM, John Hildenbiddle [e-mail] wrote:

The question I asked here and here remains unanswered:

Is there a threshold that needs to be crossed before a new option is considered?

Seems like a reasonable question, no?

If no, say so. If yes, explain. If unsure, state that and consider being a little less certain and contradictory while reviewing the issues this feature request would address as outlined in this thread and many others. Otherwise, why keep this thread open except to maintain a meaningless void for folks to yell into?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[jakeNiemiec]

The status:needs discussion label was added on Mar 1, 2017

That was nearly 1000 days ago.

I think the discussion has been fulfilled showing a clear desire from the community.

[IRCraziestTaxi]

Seriously, can we please get this option? This is one thing I cannot compromise on. Same-line elses, catches, etc. destroy readability IMO and in several other folks' O's it would seem.

[phaux]

I think it should be the default in Prettier 2.0 👀

[atlep]

I came here because this style forces me to do extra work when copying and pasting a block, temporarily commenting out a block or similar.

I really think:

if (a) {
  ...
}
∕∕ else {
∕∕  ...
∕∕ }

makes more sense than:

if (a) {
  ...
} ∕∕ else {
∕∕  ...
∕∕ }

Please add this option to make code prettier and easier to work with. 👍

As of now I tend to end if statement blocks with } // as a work around.

[alexander-akait]

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

[j-f1]

You can also do this (which is what I usually do):

if (a) {
  ...
// } else {
//   ...
}

[bdougherty]

Wow, so they will add options #6157 and they even changed it from a more generic option that could have been used with other things like Svelte, to a framework-specific option.

[atlep]

@evilebottnawi Just linking to the philosophy, without explaining what in the philosophy is relevant to the discussion, tells me nothing. ¯\_(ツ)_/¯

I think coding style should facilitate reading and editing the code.

[alexander-akait]

@bdougherty @atlep @phaux why do not use an eslint rule for this and use prettier + eslint chain?

[atlep]

I could list a couple of reasons (tslint doesn't have the option (although it seems it can be added with an extra package), webpack reloading code more times during the process, extra complexity added to the project setup just to fight issues that could be fixed), but I'm not going to stay here and argue over this any more than I've already done.

I think there are really good reasons to add the option, it seems to be a popular issue, and I think prettier would benefit from it.

"What do people really want in 6 months?"

We still want this!

[alexander-akait]

webpack reloading code more times during the process, extra complexity added to the project setup just to fight issues that could be fixed), but I'm not going to stay here and argue over this any more than I've already done.

:confused:

As the webpack developer i strongly recommend remove prettier/linters/other stylistics stuff from webpack build and use these packages via CLI or Node API

[atlep]

@evilebottnawi Webpack can watch for file changes and reload the project when files are modified. As would happen when running prettier or a linter with fix option from cli.

[LamaAni]

Must say, when so many ppl are in need for a feature and the maintainers don't listen - seems like a bad move. This behavior would mean that when (not if) another option will be available, many would consider it.

I, for one, also support adding options when so many people are requesting them. I am also in dire need for this one.

Sad

justmy2cents

[nealoke]

This project is great but this is so annoying when you want to use prettier in your projects. 😢
Why does prettier refrain from adding options?

[lydell]

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

[IRCraziestTaxi]

@lydell I really wish people would stop linking to the "option philosophy" as if that quells this very clear desire from the community. So many people believe that new lines make code much more readable. Throwing the philosophy link at us and calling it a day leaves us stuck with a huge opinion to force on people using this otherwise fantastic tool that keeps code nice and clean and standardized effortlessly... except for one of the most important options that could be available to a developer trying to standardize their code base.

[lydell]

@IRCraziestTaxi That was not my intent. It sounded like @nealoke didn’t know that Prettier tries to have very few options, so I linked to the best page we have currently to let him know.

[lambert-velir]

I have been using "brace-style": [1, "stroustrup"], in eslint with https://github.com/prettier/prettier-eslint and it's been working fine for me in Atom.

However, some of my team uses VsCode, and the https://github.com/prettier/prettier-vscode plugin has deprecated prettier.eslintIntegration, which breaks prettier-eslint. 👎 I can't get the prettier to play nicely with the above eslint rule.

+1 for this option!

[leilapearson]

Please count me in as another user requesting this option.

I don't mind how the code looks when I have just a bare else - though I would prefer it to start on a new line so the if and else line up.

What's really bothering me is the readability with "else if".

Try reading this:

if (some expression) {
  doSomething();
  doAnotherSomething()
  doYetAnotherSomething();
} else if (some other expression) {
  doSomethingElse();
  doAnotherSomethingElse();
}

vs:

if (some expression) {
  doSomething();
  doAnotherSomething()
  doYetAnotherSomething();
} 
else if (some other expression) {
  doSomethingElse();
  doAnotherSomethingElse();
}

It looks even worse if you follow a style where you like to put a blank line between a variable declarations section and the rest of the block :

if (some expression) {
  let myVar = something;

  doSomething();
  doAnotherSomething()
  doYetAnotherSomething(myVar);
} else if (some other expression) {
  let myVar = something else;

  doSomethingElse();
  doAnotherSomethingElse(mmyVar);
}

[n1ghtmare]

I love prettier, but this is driving me absolutely nuts. Everything else is perfect. I hope the maintainers reconsider this being at least an option. I know it's an "opinionated" formatter, but, come-on look how many people ask for this.

[jhildenbiddle]

Consider:

Prettier 1.19 - November 9, 2019

This release adds the long awaited --vue-indent-script-and-style option...

Long awaited... since February 4, 2018. Here's the vote count on that issue (#3888):

And the current count on this issue which has been around since March 1, 2017:

Nobody is suggesting that GitHub votes alone should determine which features will or will not be added to prettier. That said, they do exist for a reason and shouldn't be dismissed for the sake of expediency.

The rational for including a breakBeforeElse-like option goes well beyond personal preference:

• It addresses code-folding behavior in some IDEs
• It addresses warning/errors when trying to get similar behavior via ESLint
• It addresses current inconsistent output when using comments above if, else if, and else statements
• It produces cleaner diff and merge output
• It is (objectively) easier for humans read

It's hard to understand how these benefits do not meet the high "opinionated" bar for consideration while options with far fewer benefits have been added in recent versions (1.19, 1.17, and 1.15) without issue.

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

So then, how have teams managed the addition of recent options like --vue-indent-script-and-style (1.19), --quote-props (1.17), and --jsx-single-quote (1.15) without descending into chaos?!

[n1ghtmare]

@jhildenbiddle I couldn't have said it better. Also (and I know this is anecdotal, but) in my 15 years of working professionally as a programmer with C like syntax languages, I've (very) rarely (i.e. read - never?) seen the format that is implemented by prettier, and I believe there is a reason for that - else on a new line is just easier to read and gives a clearer separation of logical code branches. Again, if it's a big deal, fine, don't make it the default, but at least give us the option.

[ryuk3t]

A two-years-issue...could not be solved by giving an option?
Hopefully, this option can be released in 2020 ;)

[faisalhakim47]

I dont understand what is stoping this issue. The community is in clear positive direction.

If it goes againts the prettier philosophy, and if the philosophy is what prettier really stand for, then close the issue! end the discussion, because there will be no discussion can be made anymore.

[lax4mike]

Prettier 2.0 just got released, and I'm very disappointed that nothing has happened to fix this issue in the last 3 years. I think there has been sufficient objective reasons to add this option.

Can we reevaluate this now?

@vjeux @duailibe @j-f1 @azz @lydell @evilebottnawi @BPScott @CiGit @duailibe @ikatyang @jlongster @kaicataldo @kddeisz @kentcdodds @lipis @mitermayer @nickmccurdy @not-an-aardvark @ntotten @patrick91 @shannonmoeller @Shinigami92 @sosukesuzuki @suchipi @zertosh @zimme

[Shinigami92]

https://github.com/prettier/prettier/pull/6017#issuecomment-478219508

If the feature is not wanted, we may close this issue 🤔
Otherwise implement it

Edit: I see... one comment above yours... https://github.com/prettier/prettier/issues/840#issuecomment-599206235 😂 same opinion, do it or close it

[IRCraziestTaxi]

In response to @Shinigami92's comment: this feature is FAR from not wanted. There has been MASSIVE demand from the community, as easily evidenced by this three-year-old issue.

I do begrudgingly say that if the maintainers refuse to give into the justified demand, then close it so we can move on.

Personally I have found that eslint has rules and fixers for pretty much everything I need so I really do not see the need to use prettier anymore, but I do say that given the demand from the community with their reasons for wanting it, it really should be implemented.

[wongjiahau]

I like every rules in prettier, just not noBreakBeforeElse

[codxr02]

IMPLEMENT IT

[wongjiahau]

Please we need this, my code became harder to read because of this rule.

[langdonx]

same opinion, do it or close it

Easy then, do it!

[phaux]

I agree that it's not worth it to have an option for this, but I still don't understand why it wasn't changed to default after 3.0. There was other changes that had bigger impact on the code base and was only a matter of stylistic preference, while this has a few actual advantages. Also, the PR implementing this was only a few changes and it was rejected.

[phaux]

The only argument I've seen for this current syntax so far is "because everybody does it" which is not an argument at all.

[JoshMcCullough]

The only argument I've seen for this syntax so far is "because everybody does it" which is not an argument at all.

Not an argument, and also not even true!

[lax4mike]

The only argument I've seen for this syntax so far is "because everybody does it" which is not an argument at all.

@phaux I'm not sure what you mean by this? Are you referring to the Stroustrup indentation syntax?

Either way, this thread is full of valid objective reasons to use Stroustrup, which you summed up here: https://github.com/prettier/prettier/issues/840#issuecomment-522273393

• It's one of the standard styles besides 1TBS and Allman
• It's better for line-oriented operations and commit diffs
• Easier to scan visually, because the keywords line up

In addition:

• It's cleaner to comment _above_ an if/else block
• It's cleaner to comment _out_ an if/else block (https://github.com/prettier/prettier/issues/840#issuecomment-555533342)
• It makes it easier to discern blocks of code (https://github.com/prettier/prettier/issues/840#issuecomment-581182600)
• The current prettier behavior regarding this is inconsistent (https://github.com/prettier/prettier/issues/840#issuecomment-482396204)

Moreover, it's currently _impossible_ to use Stroustrup with the recommended eslint integration outlined here as demonstrated by @dpipchenko here https://github.com/prettier/prettier/issues/840#issuecomment-521097308 and here https://github.com/prettier/prettier/issues/840#issuecomment-573472027

CC @vjeux @duailibe @j-f1 @azz @lydell @evilebottnawi @BPScott @CiGit @duailibe @ikatyang @jlongster @kaicataldo @kddeisz @kentcdodds @lipis @mitermayer @nickmccurdy @not-an-aardvark @ntotten @patrick91 @shannonmoeller @Shinigami92 @sosukesuzuki @suchipi @zertosh @zimme

[kentcdodds]

Could we stop mass-mentioning people please?

[leilapearson]

Sadly, without BreakBeforeElse, _prettier_ is failing to live up to its name and is making my code _uglier_.

By _uglier_ I don't mean by some personal and subjective standard of beauty. I believe it is _clearly and objectively_ making the code harder to read.

Before prettier:

if (someCondition) {
  const someData = 1;

  doSomethingWithSomeData(someData);
  doAnotherThing();
}
else {
  const someOtherData = 2;
  const evenMoreData = 'more';

  doSomethingWithSomeOtherData(someOtherData);
  doYetAnotherThing(evenMoreData);
}

After prettier:

if (someCondition) {
  const someData = 1;

  doSomethingWithSomeData(someData);
  doAnotherThing();
} else {
  const someOtherData = 2;
  const evenMoreData = 'more';

  doSomethingWithSomeOtherData(someOtherData);
  doYetAnotherThing(evenMoreData);
}

Does anybody looking at the after prettier example actually find it easier to read?

The problems I see are:

• It buries the else and makes it harder to pick out _(yes, syntax highlighting would help a bit with this issue)_
• It makes it look like all of the code around the else belongs together, instead of the code in each block belonging together.

@jhildenbiddle issuecomment-587960190 and @lax4mike issuecomment-612279210 have listed a lot of great additional reasons to support this option too.

I understand wanting to limit the number of options. Prettier is supposed to be opinionated and I'm more than fine with that. I've read the policy on adding options, and it makes sense as a general guideline.

What I don't understand is why the prettier maintainers aren't looking at all of these comments and saying to themselves:

These are some really good points. If we were writing prettier today, we'd make break before else the default behavior. We can't go back in time, but changing this behavior makes sense, so let's go ahead and add an option.

[nickmccurdy]

Prettier is about community conventions. I haven’t seen a JavaScript project use this style in at least 10-15 years, so I wouldn’t consider it a convention personally. As others have already said, if you need this, you can create a pull request. I don’t think this conversation is very productive without an implementation to discuss.

[bdougherty]

@nickmccurdy there was an implementation, and it was closed: #837

I haven’t seen a JavaScript project use this style in at least 10-15 years, so I wouldn’t consider it a convention personally.

I've never worked on a project that did not break before else, JS or any other language, until recently when I started working on one that uses Prettier. And for the record, nobody likes the style, but they use Prettier anyway for the other benefits.

[nickmccurdy]

It seems like this implementation was for a fork of Prettier that uses this formatting style without options. Perhaps it could be reopened with this option off by default, so it can still be used by current Prettier users without breaking their formatting. You could even create a branch based off that pull request's branch, so all you have to do is update it and implement the option.

__Disclaimer:__ I am not a Prettier maintainer, I'm not sure if that would be accepted but it's worth trying

[jakeNiemiec]

It's called a Cuddled Else Block. Check this out from the 90's: https://wiki.c2.com/?CuddledElseBlocks

This is the oldest 1TBS reference I could find on Google. C programers seemingly used 1TBS (one true brace style) while C++ programers used Stroustrup (C++ creator)

Can we at least agree that a style with 30+ years of history behind it should be considered?

[Shinigami92]

@jakeNiemiec Does Prettier support C from scratch? 🤔
If there is a plugin that supports C, the maintainer can decide to support it for C. Please open an issue in the plugin's repo.

[wongjiahau]

@Shinigami92 it's not about C.
Dear contributors and maintainers, do you mind to explain your concern over this uncuddled-else feature?

[Shinigami92]

@wongjiahau Sorry if it wasn't clear, my comment was only related to the one above my comment.
There, only arguments and sources about C are presented.
Will edit the comment to make that clear.

[IRCraziestTaxi]

@Shinigami92 I think they were just referencing the history of the "cuddled"/"uncuddled" brace styles, which go back to the C days. Nothing to do with prettier and C directly.

Also, I second @wongjiahau's request for the contributors and maintainers to explain their concerns over this feature.

[jeemok]

I really wish there is an option in prettier to break the line for people like us, now I have started removing the else in my code altogether

Before:

// This does something
if (a) {
  ...
}
// This does something else if
else if (b) {
  ...
}
// This does something else
else {
  ...
}

Now:

// This does something
if (a) {
  ...
}
// This does something else if
if (b) {
  ...
}
// This does something else
...

[faisalhakim47]

I really wish there is an option in prettier to break the line for people like us, now I have started removing the else in my code altogether

I hope you are not serious. But if you do, you have to be careful there, it is doing totally different thing. For example, the else in the end does not work the same way as the code before.

[leilapearson]

Has anyone already suggested the option of prettier simply allowing a newline before an else if you happen to insert one?

There are plenty of places where prettier will allow you to manually insert a blank line - and prettier already lets you manually insert comment lines there. Maybe this could be handled like that?

It won't satisfy everyone since code will no longer be guaranteed to be consistently formatted with respect to break-before-else style, but at least it would allow people to manually break-before-else if they want to.

I thought I'd mention this option since you could potentially change the behavior without adding an option at all. It wouldn't affect any existing code. It would just allow more flexibility in new code.

Can any prettier maintainer let us know if this might be a more acceptable way to approach this problem?

Personally I'd be happy with this for my code, but I'm not sure how others would feel about it.

[leilapearson]

Has anyone already suggested the option of prettier simply allowing a newline before an else if you happen to insert one?

There are plenty of places where prettier will allow you to manually insert a blank line - and prettier already lets you manually insert comment lines there. Maybe this could be handled like that?

It won't satisfy everyone since code will no longer be guaranteed to be consistently formatted with respect to break-before-else style, but at least it would allow people to manually break-before-else if they want to.

I thought I'd mention this option since you could potentially change the behavior without adding an option at all. It wouldn't affect any existing code. It would just allow more flexibility in new code.

Can any prettier maintainer let us know if this might be a more acceptable way to approach this problem?

Personally I'd be happy with this for my code, but I'm not sure how others would feel about it.

[lydell]

Hi @leilapearson! Thanks for the suggestion! Respecting original code formatting is something we always try avoid as much as possible, since that’s pretty much the point of Prettier – Prettier should make decisions for you, so you don’t have to, and can’t debate with team mates.

Here are some pros and cons of different solutions:

• Making the change for everyone. Now we’ve swapped one disappointed group for another. Is the new group smaller than the first? We’ll never know for sure. We _might_ be able to justify the change (pro), but it’s a burnout-triggering action for maintainers.
• Not making the change. Ya’ll in this thread will stay unhappy. Some will change their minds over time and stop caring, some will just grind their teeth occasionally, some will stop using Prettier. We avoid a controversy, but might miss out on a slightly superior code formatting or so.
• Adding an option. We don’t want more of those, because now we’ve given every team one more thing to debate. An option helps the two camps that already have strong opinions about the option choices, but hurt everyone who don’t.
• Respecting the input code. Now we’ve opened the door for inconsistent code and PR nitpicks. An alluring solution that seems so simple, but bit by bit undermines Prettier. Taken to the extreme, Prettier wouldn’t do anything anymore – just pass through the original code unchanged.

[Shinigami92]

I absolutely agree with @lydell!
This statement should end this discussion and we should close this issue

I would suggest that someone write a github gist deliver a patch that can be applied via https://github.com/ds300/patch-package
Then the community that wants to use this feature can provide support for this patch

[lax4mike]

@lydell

• Adding an option. We don’t want more of those, because now we’ve given every team one more thing to debate. An option helps the two camps that already have strong opinions about the option choices, but hurt everyone who don’t.

I don't think this is a statement in entirely accurate.

Prettier already has a bunch of options, including more hotly debated ones like tabs vs spaces, and seemingly pointless options, like bracket spacing. Teams will debate and settle on one, or they won't and just use the default, it's fine.

In the case of this issue, there are very legitimate reasons outlined in this thread for wanting to use _Stroustrup brace style_ and as of now, it is impossible to do so when using prettier and vscode (https://github.com/prettier/prettier/issues/840#issuecomment-612279210). This is adding more headache for my team than debating over the style.

[lydell]

@lax4mike Sorry, I think I missed your point? (Btw, just in case you haven’t seen it – have you read the Option philosophy?)

[JoshMcCullough]

@lax4mike Completely agree, and was going to mention the same. It's a "strawman", IMO. Add the option with the default as it is now and then, won't everyone be happy? Prettier will never stop developers from arguing about which formatting is best. They're gonna argue within their teams, and that's fine.

[shannonmoeller]

@JoshMcCullough I personally prefer stroustrup and would love for there to be an option, but I understand prettier's line in the sand. Adding options might make some people happy, but that could be said for a lot of things prettier will never support. If everything was an option, we'd be better off reverting back to jscs. I'm for closing the issue, even though doing so is personally disappointing.

[jakeNiemiec]

@lax4mike Sorry, I think I missed your point? (Btw, just in case you haven’t seen it – have you read the Option philosophy?)

@lydell, I think the point is that Mike's team wants to use _Stroustrup_, a very common style with 34 years of history behind it. Yet, you make option philosophy concessions for Vue, a framework released only 2 years prior to prettier. Can you at least give _Stroustrup_ a poll like you did for Vue?

Adding an option. We don’t want more of those, because now we’ve given every team one more thing to debate.

By denying a _Stroustrup_ option, you change the debate into "Do we use strict, vanilla prettier or the more lenient fork of prettier".Even today, you can see forks like PrettierX growing at 8x the usual speed:

From your comment and https://github.com/prettier/prettier/issues/7917, it seems like prettier forks will be future 👍. Please consider giving _Stroustrup_ more consideration. It isn't the same as bracketSpacing, it predates Javascript by 10 years.

---

Edit: If you scroll up, less than a year ago @lydell stated:

https://github.com/prettier/prettier/issues/840#issuecomment-522295504 Personally I wouldn't mind the Stroustrup style – even though I've never used it myself ever before! I think it makes sense. 

[wongjiahau]

To be fair we should have a poll like what @jakeNiemiec mentioned.

[brodybits]

This option is now supported by prettierx.

I do think it would be ideal to make the CLI tool strongly opinionated, with the underlying library more flexible, like standard and standardx do for "Standard JS" formatting.

[nickmccurdy]

Not worth the churn, it's easier to adopt } this { style. The purpose of Prettier is to force popular best practices to keep code consistent with other projects using Prettier. If you need to maintain an unconventional custom style and don't want to follow these practices, you're probably better off with a custom ESLint config (packages are fairly easy to publish).

[JoshMcCullough]

@nickarnold ...

}
else {

...is hardly "unconventional".

[nickmccurdy]

I haven't seen any popular JavaScript projects using that style in at least a decade

[jeemok]

I haven't seen any popular JavaScript projects using that style in at least a decade

So only popular JavaScrip projects should use prettier now?

[bopfer]

I haven't seen any popular JavaScript projects using that style in at least a decade

It's because everyone just sucks it up and uses prettier 😄 So, of course they are all going to have the same style. Doesn't mean they wouldn't prefer Stroustrup. That's the boat many of us are in. The cuddled else and catch blocks are awful for readability, but the rest is so good that we just deal with it.

[langdonx]

The cuddled else and catch blocks are awful for readability

This is 100% subjective... however there are real objective benefits to using Stroustrup:

• cleaner git diffs
• the ability to add comment on the conditional logic in an else if

I've yet to hear any objective arguments for keeping the existing style, other than "that's what we've been doing".

[nickmccurdy]

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

[langdonx]

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

I've read the whole thread and the philosophy than once. I'm not arguing for an option. Stroustrup seems like a best practice with real world advantages. =P

[nickmccurdy]

The vast majority of JS projects are using this style. I don't see how the separate line curly brace is a best practice as it's something most JS developers avoid.

[bopfer]

I don't see how the separate line curly brace is a best practice as it's something most JS developers avoid.

Sounds like you are making some drastic assumptions about what developers prefer based on what we are forced into because prettier doesn't give us a choice.

[nickmccurdy]

I’m mostly referring to projects that don’t use Prettier. Prettier adopted the style because it was the most common beforehand.

[shannonmoeller]

Recommendation: Change issue title and option name to "breakAfterBlock" to include catch, finally, if else, and things like blocks around switch cases.

[sandokanelcojo]

@shannonmoeller
And then keep ignoring it for another 2 years...

[lydell]

blocks around switch cases.

What’s an example of that?

[langdonx]

blocks around switch cases.

What’s an example of that?

Maybe another inconsistency since prettier respects curly braces around case statements though I'm not sure why as I don't believe there's any effect aside from a visual one since it affects declaration scope. I would argue braces should always be added personally, just as I wouldn't advise skipping braces around an if.

// if this is desirable (because it's compact?)
if (s === 1) {
  console.log("one");
} else if (s === 2) {
  console.log("two");
}

// why isn't this?
switch (s) {
  case 1: {
    console.log("one");
    break;
  } case 2: {
    console.log("two");
    break;
  }
}

[jakeNiemiec]

Not worth the churn, it's easier to adopt } this { style. The purpose of Prettier is to force popular best practices
Prettier adopted the style because it was the most common beforehand.

@nickmccurdy you misunderstand. I agree that } this { _is_ currently the most popular, but I don't think it _is_ "the best".

There are plenty of examples in this, and other issues: https://github.com/prettier/prettier/issues/840#issuecomment-521097308, https://github.com/prettier/prettier/issues/840#issuecomment-483027160, https://github.com/prettier/prettier/issues/840#issuecomment-581182600, https://github.com/prettier/prettier/issues/840#issuecomment-587960190, https://github.com/prettier/prettier/issues/840#issuecomment-612292425, #837, #2573, #3084, #3537, #3832, #4610, #4986, #6017. It's also certainly not "best" for devs who must use a different brace style for backend code.

---

We’ve had several users open up option requests only to close them themselves a couple of months later. They had realized that they don’t care at all about that little syntax choice they used to feel so strongly about. Examples: #3101 and #5501. All of this makes the topic of options in Prettier very difficult. And mentally tiring for maintainers. What do people really want in 6 months?

@lydell Yes, I did read the _Option Philosophy™_. Like the brace choices, I encourage you to update it for accuracy:

• Neither user "_closed the issue themselves a couple of months later_".
  
  
  
  • @damassi was "_sick of getting notifications_" and I don't think they would appreciate being linked directly on your website as a poster child of the _Option Philosophy™_.
  
  
  • #5501 didn't open or close an issue. It seems like both examples don't support what the _Option Philosophy™_ is saying.
  
  
• It's been 7 months since my first comment in this issue. I still want _Stroustrup_ because our non-JS backend doesn't cuddle else blocks.

I'll continue to _use_ prettier, but I won't agree that it _is_ prettier. 🙃

[damassi]

Neither user "closed the issue themselves a couple of months later"

To clarify about #301, I did close it myself and expressed why -- multiple times. And exactly as Lydell says. I just got used to prettier, and preferred to no longer think about these things anymore. My complaints vanished in all the positives that I was continually experiencing, and then I forgot that I ever even had preferences for such things. What I mainly wanted was consistency over style and options, and didn't quite realize that at the time because I was new to Prettier. And now I can't even remember what I used to like! Less is more.

[jakeNiemiec]

What I mainly wanted was consistency over style and options.

I am happy this works for your code; you probably don't have a backend that uses _Stroustrup_, this is the consistency we are looking for here.

---

I just got used to prettier, and preferred to no longer think about these things anymore...I forgot that I ever even had preferences for such things...I can't even remember what I used to like!

The term _Procrustean Bed_ comes to mind:

Procrustes kept a house by the side of the road where he offered hospitality to passing strangers, who were invited in for a pleasant meal and a night's rest in his very special bed. Procrustes described it as having the unique property that its length exactly matched whomsoever lay down upon it. What Procrustes didn't volunteer was the method by which this "one-size-fits-all" was achieved, namely as soon as the guest lay down Procrustes went to work upon him, stretching him on the rack if he was too short for the bed and chopping off his legs if he was too long. (link)

Simon, if you do reach the _Option Philosophy™_ goal of having an no options, renaming Prettier to Procrustes would be an excellent way to convey your demand for conformity. 👍

[Shinigami92]

All examples I see of this Stroustrup and not cuddled else are C++?!
Has anyone a repository with more then 1k stars and JS/TS that uses this style? Please link

[jakeNiemiec]

Has anyone a repository with more then 1k stars and JS/TS that uses this style? Please link

@Shinigami92 🤣 How about the 9th most starred repository in all of Github? All of the examples in Kyle Simpson's JavaScript book series use _Stroustrup_ braces. An example and several other examples.

_{Or even a clipboard utility with 28,400 stars. I also found several example where prettier absolutely mangles if/else readability, eg: VueJS source}

Granted, Stroustrup is not as popular as 1TBS is for Javascript, I said as much here. If you need even more examples try Github's advanced search, there are plenty above 1k.

[ryuk3t]

For people who want to use the breakBeforeElse rule in eslint:
there is a solution:

• .eslintrc.js

yarn add prettier eslint-config-prettier eslint-plugin-prettier --dev

```js
parser: '@typescript-eslint/parser',
extends: [
'plugin:react/recommended',
'plugin:@typescript-eslint/recommended', // Uses the recommended rules from the @typescript-eslint/eslint-plugin
'prettier/@typescript-eslint', // Uses eslint-config-prettier to disable ESLint rules from @typescript-eslint/eslint-plugin that would conflict with prettier
],

- use VSCode with `.vscode/settings.json` & install eslint/prettier extension
```json
{
  "eslint.autoFixOnSave": true,
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    { "language": "typescript", "autoFix": true },
    { "language": "typescriptreact", "autoFix": true }
  ],
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

ref: https://dev.to/robertcoopercode/using-eslint-and-prettier-in-a-typescript-project-53jb

[jhildenbiddle]

This thread is a master class on how not to engage a community.

The discussion here should focus on the merits of a brace style currently not supported by Prettier and whether or not those merits warrant adding a new option to support it despite Prettier's very well understood philosophy about limiting the number of options it offers.

With this in mind, I think we would enjoy significantly more progress on this consistently active 3+ year old issue if people considered the following before posting:

• Everyone understands Prettier's Options Philosophy, so enough with the mic-drop attempts (e.g. repeatedly linking to to the Options Philosophy page). This issue remains active not because participants are unfamiliar or disagree with Prettier's Options Philosophy, but because they believe the lack of support for Stroustrup brace style is equally if not more important than other options the maintainers made exceptions for and implemented despite the project’s stated philosophy.

• Personal anecdotes and opinions like which brace style you prefer, your limited exposure to other brace styles, how popular you believe other brace styles to be, or how you had a style preference that Prettier wouldn't let you change but eventually you learned to conform to the way Prettier does things and now you're happy so others should just do the same thing adds zero value to the discussion. If you believe others will find your personal journey and opinions unrelated to this issue interesting, start a blog or a YouTube channel and prepare yourself for internet fame.

• Focus on the topic at hand--the merits of Stroustrup brace style compared to 1TBS--before getting sidetracked by other concerns. This means considering the advantages described by proponents of Stroustrup style, not just the technical and philosophical ramifications of implementing a new option. Explanations for why 1TBS is the preferred style (other than "it's popular") would be a welcome addition to the conversation as well. There will be plenty of time to consider the how, when, and what if's associated with supporting an additional brace style after it has been decided that an option is worth adding.

Finally, it's worth reminding everyone that while Prettier is very popular and therefore influential in setting developer expectations and preferences, Prettier is no more the standard bearer for how JavaScript (or any other language) should be formatted than jQuery is for manipulating the DOM, Internet Explorer is for browsing the internet, or the VCR is for watching movies at home. Prettier's decision to adopt 1TBS as its one-and-only supported brace style does not mean 1TBS is the one-and-only JavaScript style standard, nor should it prevent Prettier from considering alternatives when they are proposed. It simply means the maintainers of Prettier decided 1TBS was the most "popular” at the time. The same can be said for jQuery, Internet Explorer, and the VCR back in their day, too.

Edit: Down votes from the most glaring offenders welcome.

[lydell]

@jhildenbiddle Well put. 🏅

(Note: My intention is to only bring up the Option philosophy when someone mentions something they wouldn’t have said if they’d read it. But point taken – I might have linked to it a bit too much.)

[wongjiahau]

When can we get this included?

[retnikt]

Who objects to you adding this option? Nobody.
Who objects to you not adding it? Hundreds of people in this thread.
Solved.

[wongjiahau]

Hi guys anyone want to volunteer on this?

[jakeNiemiec]

Hi guys anyone want to volunteer on this?

There are a few existing PRs linked above.

[lambert-velir]

@jakeNiemiec who decides if those PRs are merged?

[jakeNiemiec]

@jakeNiemiec who decides if those PRs are merged?

See https://github.com/prettier/prettier/issues/840#issuecomment-602264798

[langdonx]

Don't get your hopes up.. https://github.com/prettier/prettier/pull/8540

[Anoesj]

I tried Prettier for 1 day, but the lack of this feature is a dealbreaker for me. The elitism by the pro-1TBS folks in this thread astounds me. Tastes differ, deal with it and listen to your community already.

[damassi]

Well, that's a good way to approach technology choices 👏

[AlchemistCamp]

Just throwing in my 2¢ and mentioning that I've also decided to uninstall Prettier and revise the tutorials where I've previously included it due to this issue.

I understand and respect that Prettier is an opinionated project and I'm opinionated too. Unless being paid a salary to do so, I won't be using a tool that makes my commits messier and makes else statements fail to line up with their corresponding if statements.

E.g.

  if (cond1) {
    // blah blah blah
    if (cond2) {
      collect(tree.left, data, depth + 1);
      collect(tree.right, data, depth + 1);
    }
  } else {
    // the above else lines up with unrelated if
    doFoo(data);
  }

[zoran-grujic]

Yes, this feature is must have. The code is more readable with break before elseand else if and catchand finally. Stubbornness of developers is really amassing! Yes, I am going to stop using prettier due this issue, specially as developers REFUSE to consider such important option. Option philosophy is just opinion that could be changed or re-interpreted if there is good will. There is no law or constitution that cannot be changed by (good) will of people.

[damassi]

Y'all, just fork prettier and update it yourself. I'm sure someone in this thread can easily add a breakBeforeElse rule in a couple hours. Then drop that fork link right here in this thead! 🍻

This feature will never land in Prettier (that ship has sailed) but the beauty of open source is that you can tweak the code however you wish and share it with others.

Or perhaps https://github.com/brodybits/prettierx will take your case? Its an active fork.

Edit:

Ah! well look at that. Checking the docs, they already have a breakBeforeElse rule.

[AlchemistCamp]

Y'all, just fork prettier and update it yourself.

Relying on a fork is generally more dangerous than finding a competing project more attuned to its community. In my case, that means using ESLint as I was before and keeping an eye on the development of newer tools that might make different choices or be less restrictive.

My comment above was just feedback in the open and a placeholder for why I'm no longer using the library.

This feature will never land in Prettier

That really is a shame. I'd never imagined Prettier was so set on this issue given the drawbacks. Thanks for making the situation clear, though.

[damassi]

https://github.com/brodybits/prettierx is the place to propose new features, and it includes breakBeforeElse, so def check that out.

[Godrules500]

Is this still not on the radar to be done? This is my biggest issue with using prettier as well and would really like it if they added some additional options like this.

[merlinpatt]

Summary: Make breakBeforeElse the final option ever added

Prettier has core philosophies of being opinionated, making code consistent, and making code easy to read. Prettier already formats most code in easy to read blocks where the start and end of a block are in the same column.

Since Prettier wants to stay opinionated and stop having code format discussions, the solution is simple:

Make breakBeforeElse the final option that you ever add to Prettier.

In Depth Analysis

Chiming in here as well. I've always tended to want "perfect" code format so much that at one point in my career, I customized every single ESLint rule they had. While I still want "perfect" code, my definition of "perfect" now boils down to consistency and ease of editing, which I believe is a core philosophy of Prettier and why so many people use it.

There are a few odd things that I prefer in my code that I rarely see most people do, but I've stopped caring about them unless it's a project I start myself. For instance, I prefer single quotes everywhere, including on HTML and JSX attributes because it's slightly easier to type a single quote than to hit shift and type a double. But with prettier and other tools, I no longer have to care. And something like double vs single quote doesn't make editing any easier or harder. Similarly, I prefer no bracket spacing and arrow parens but these usually don't affect ease of editing. If they do, there are usually other issues with the code (like a function returning a function returning a function...).

The things I've mentioned above are directly mentioned in the Options Philosophy page as --arrow-parens, --no-bracket-spacing, and --jsx-single-quote. My point is that I agree that options like these are unnecessary and do not affect ease of editing. And as long as they are consistent throughout, it shouldn't matter. So having those does go against Prettier's core philosophies and mine as well.

But I call special attention to --jsx-bracket-same-line that is mentioned. Not because it should exist but because it shouldn't. And the reason it shouldn't exist is actually the same reason that breakBeforeElse should!

Looking at the example given in the docs (which I'll paste below as well), there is a clear difference in readability between the true example and the default false example. When true, it is difficult to know when the attributes end and when the content begins. When false, it is very easy to read and edit.

This decision holds true in almost every other bit of code that Prettier formats. With a long list of imports, the import keyword and closing brace are in the same column and the end brace is not on the same line as the final import. Object braces align and with nested objects, the end brace aligns to the key, not at the end of the object definition. I've given examples of these below as well.

In every single case, Prettier's formatting is easier to read and edit and even comment out.

Except one: If Else Blocks.

As given in the example below, with breakBeforeElse set to true, Prettier would format this in a way that is consistent with all other formatting decisions. breakBeforeElse matches the pattern of starting and ending a code block in the same column.

Furthermore, the breakBeforeElse style is used in AirBnB's linting rules , which has almost 100,000 stars on GitHub and its corresponding eslint-config-airbnb-base package has nearly 3,000,000 weekly downloads. So this format is not just some fringe group of a dozen developers.

Based on all this evidence and Prettier's own philosophy of code consistency and easy to read/edit code, it only makes sense that this option be the final option added to Prettier.

If Else Formatting

If Else Examples
breakBeforeElse is true	breakBeforeElse is false
if (isSomething) { runSomeFunction(); } else if (isAnother) { runAnotherFunction(); } else { runDifferentFunction(); }	if (isSomething) { runSomeFunction(); } else if (isAnother) { runAnotherFunction(); } else { runDifferentFunction(); }

Current Prettier Format Decisions

--jsx-bracket-same-line Doc Examples
false (Good, Default)	true (Bad)
<button className="prettier-class" id="prettier-id" onClick={this.handleClick} > Click Here </button>	<button className="prettier-class" id="prettier-id" onClick={this.handleClick}> Click Here </button>
Import Examples
Good	Bad
import { someThing, anotherThing, aReallyLongNamedThing, } from 'some-packages';	import { someThing, anotherThing, aReallyLongNamedThing} from 'some-packages';
Objects / Nested Objects
Good	Bad
{ a: 1, b: 2, nest: { c: 3, } d: 4, }	{ a: 1, b: 2, c: 3, nest: { c: 3} d: 4, }
Arrays / Nested Arrays
Good	Bad
[ 'a', 'b', [ 'nestedC', ], 'd', ]	[ 'a', 'b', [ 'nestedC'], 'd', ]

[wongjiahau]

@merlinpatt The AirBnB linting rules actually mention otherwise:

[merlinpatt]

@wongjiahau ah, it's late and somehow I misread AirBnB's page. Regardless, the rest of my logic is solid. And it's still true that this isn't just a fringe group of devs who want this.

[wongjiahau]

@merlinpatt No worries. I also wanted this feature (look at my previous comments), I just think that citing a wrong reason is not going to be helpful for our agenda.

[merlinpatt]

Well, one thing that might settle this is to get some hard stats. It's a while away, but I just suggested to StackOverflow that they collect data on code style preferences in their next survey. And I think that would be a very interesting data set.

Alternatively, I feel like this data could also possibly be collected by running a program to find and gather all the linter configs out there and determine the popularity of various rules/styles. But I'm not sure where to begin with that query.

[fightingcat]

AirBnB must have a very tight space in their office, since they value space so much.
(I'm going to disable prettier anyway.)

[ovidiu-mihalcea]

I'm a junior programmer, I have no 1000 star rating. Actually today is the day I found out about prettier, as I'm learning Javascript, and intend to use VSCodium more than before. And I, of course, wanted this feature as an option as I've discovered that Prettier basically makes it harder for me to read my own code! I've hoped to have this as an option and landed on this page. I'm not gonna go around the bush here, the sheer arrogance of the developers is just astounding. The way they have chosen to deal with basically hundreds of people asking for a simple (but for them clearly important) feature should become a text book case on how not to alienate your community.

Long story short, after really enjoying it for a couple of hours, I will definitely uninstall it and see if there is something else that I like. But even if not, please allow me to also be opinionated, as I prefer to beautify my own code rather than use your extension.

[FrankyBoy]

This is really the final nail in the prettier coffin for me.

[merlinpatt]

According to this article, for every one customer complaint, there are 26 more unhappy but silent customers.

Over 150 people have left positive reactions to the initial post, meaning that they're unhappy with prettier's lack of a breakBeforeElse option, which means that there are at least 3900 other people who are also unhappy about this but have yet to say anything.

And I think it's fair to assume that that number is much much higher than that. I won't make up numbers, but that article is about paying customers. For open source and free things, it's logical to assume the ratio is more than 26 to 1.

Additionally, that article states that 13% of unsatisfied customers will tell more than 20 people. So 13% of 3900 is just over 500, and when each dev tells 20 other devs to not use prettier, that's 10,000 devs who will hear that message.

So that's nearly 14,000 people who won't use prettier because it lacks a very reasonable and very logical formatting request.

Finally, as I stated before, add this in and make it the last discussion ever.

[wtlgo]

Adding my 5 cents.
I absolutely love this plugin, it's beyond awesome, and this is the _only_ thing I absolutely hate about it. I am going to use prettier anyways, though, every single day I see that absolutely meaningless } else { thing in my code, I check this issue hoping that maintainers finally agree to add this option. Just let's be honest, it costs absolutely nothing to add it, and though it's an opinionated code formatter, too many people have an opinion that this option _must be present_. Too many to blatantly toss it away as it happens here.
I highly doubt my grumbling would change something, though hope dies last.

[syy1125]

Easy fix - just don't use else statements. /s

On a more serious note, here are my thoughts on this topic

1. Readability. I believe we format code primarily because both others and our future selves need to read the code and understand what it's doing. For me, } else { hurts my ability to read code. Everything's so cluttered, I have to spend extra effort deciphering what's going on around that statement. Obviously it's not just me, seeing how many others support this issue.
2. Broader impact. prettier is a popular javascript formatter, so it's fair to say that it will influence how the js community as a whole format their code in the future. I understand that 1TBS is the most popular style at the time prettier was made, but for those who don't like 1TBS, prettier is making it harder to switch to a different style. Maybe a lone developer could switch to eslint or prettierx on a fresh project, but what about existing projects that have multiple plugins that depend on prettier? What about teams, where a change in formatter could potentially disrupt everyone's workflow?

Regarding options philosophy - the different brace styles, and debates about which one to use, have been around for a long time. As far as I can tell it's not going away anytime soon. In 6 months, there will still be many developers who want a breakBeforeElse. The issues and "we don't want more of these" examples cited in the options philosophy are ones that are (IMO) relatively easy to adapt to, they don't have such an impact on readability, and most if not all of them haven't been around for as long as the different bracing styles have. So I feel that the points made in options philosophy do not apply in this particular case.

For now, I tolerate prettier despite the lack of breakBeforeElse, but I do hope it will become an option in the future.

[waitingsong]

AirBnB

Cause AirBnB focus on space~

[goxr3plus]

Guyz what is happening with this . Our team has conflict just because of this missing property :
breakBeforeElse

[damassi]

@goxr3plus - use https://github.com/brodybits/prettierx - it has that option.

[goxr3plus]

@damassi How to configure it to work with vs code and Webstorm :)? I mean we already have prettier plug in..... how we configure prettier x to be default formatter :)

[Shinigami92]

@goxr3plus Please forward this message in the related repo, that's not a question related to prettier itself and will not be solved here.

[goxr3plus]

@Shinigami92 I agree :).

It's just redicoulous i see all these discussions here fighting like childs when prettierx has implemented all the above properties giving freedom on how you want to style and here they are discussing it 2 years. It's just redicoulous. 1 damn property which gives more freedom and all these discussions. Unbelievable.

Sincerely yours "Karen"

[Shinigami92]

@prettier/core Can we close this issue and lock it? The work-around to solve this should be to use the addressed repo.

[FrankyBoy]

@Shinigami92 no why? This issue is not resolved. Workarounds (which would that even be? "don't use prettier"? great workaround ... NOT) are not solutions.

[AlchemistCamp]

@Shinigami92 no why? This issue is not resolved. Workarounds (which would that even be? "don't use prettier"? great workaround ... NOT) are not solutions.

That _is_ the workaround. I don't use prettier or any related because of this issue. For now, I'm just using a less opinionated tool.

Rome looks like it may end up being the best replacement: https://github.com/rome/tools/issues/1024

[Shinigami92]

I'm team prettier, therefore I will not name related tools, but using competitors are an option and maybe will improve the tool marked out there.
Keep in mind that Open Source projects are there to improve the world and making e.g. developers more happy.
Prettier tries to help developers by formatting their code with as few options as possible so they do not think about these options but just using the tool.

Other competing tools uses other strategies, and I'm totally fine with that. :slightly_smiling_face:

[goxr3plus]

@Shinigami92

If prettier makes 1000 people happy now. It will make 10.000 more happy with some extra properties. We are developers we need flexibility.

Prettier is awesome but we are 20 people in our team 16 wants to use breakBeforeElse i respect their opinion as as team leader want to give them that option. I don't force because i am the boss. Whatever i am done with this repo.... "Making people happier by forcing to use one style and denying to add a property for two years" , you are childs. I feel so bad our team has to change tool.

[damassi]

Prettier is awesome but we are 20 people in our team 16 wants to use breakBeforeElse

This thread, at this point, is like not being able to see the forest through the trees.

If you use prettier, you don't have to think about these things anymore. These are style concerns.

Prettier's design is intended to be minimal, to not offer options. Why? Because human beings are adaptable. Once you start using a code formatter with its defaults, you get used to it in literally no time and don't even notice anymore. Your favorite website gets a redesign. You hate it. Then you don't notice it anymore, in less time than you imagined. You might even begin to like it, and realize that your knee-jerk reaction was unwarranted. You just needed some time to adapt. With Prettier, your so-called opinions fade away by virtue of the benefits experienced by not having said opinions. The authors and maintainers of Prettier know this intimately, and that's why style-related feature requests like this will never, ever succeed. That ship sailed v1.0.

Remember:

Cmd+s, plus an editor = format on save. You can write slop, never use the tab key to indent, etc, and you hit Cmd+s and things magically snap into place. It saves an enormous amount of energy. And the amount of energy saved, across a given work week, is _very significant_.

Why?

Because now, in addition to writing code, when you read other peoples code, it looks consistent everywhere. That includes across repos and across teams. It saves energy, because your eye is already famiilar with the style. Adding breakBeforeElse means that code that uses it would be shifted downward, eliminating some of that efficiency, and thereby increasing the amount of energy required to do ones job. Less is more here. There's a reason behind less options. And not using the tool just because x, y or z option isn't there means that the numerous other things that vastly improve the developer experience are also lost. This all or nothing approach championed by some in this thread is really a bit overly dramatic.

@goxr3plus

How to configure it to work with vs code?

You can set the prettier binary in the VSCode settings. You can point it at whatever you want. Just point it at prettierx, which has all of the settings everyone here needs. Problem solved, issue closed. And if for whatever reason you can't set the binary directly, just alias prettier at the system level: alias prettier = prettierx.

[AlchemistCamp]

This thread, at this point, is like not being able to see the forest through the trees.

If you use prettier, you don't have to think about these things anymore. These are style concerns.
...

Your entire comment could be used to defend literally _any_ styling choices, even ones that deliberately misaligned conditional branches with others at its logical level (much like prettier already is doing on a small scale in the example I referenced).

Yes human beings are adaptable, but some things are easier to adapt to than others. It's objectively easier to spell Spanish than English, for example. It pays off to have consistency at a deeper level than simply making the same idiosyncratic choices each time an identical situation comes up.

[thorn0]

Closing because creating a configurable formatter is a non-goal for this project. Thanks for the feedback.

[alexander-akait]

@thorn0 I still think that we can find a certain compromise here. This is a popular feature, or at least we should provide API for library specific logic, so that this can be achieved with a small plugin

[thorn0]

@alexander-akait Not sure what you mean. This is not library-specific at all.

[alexander-akait]

@thorn0 Yes, not specific, but I think API for library specific code should allow to hook AST nodes and allow to write custom output, so in theory it can be can achieved using plugin

[thorn0]

@alexander-akait Plugins already can do that, but that's really a separate topic, which has its own open issue. This issue is about adding configuration to the core, which explicitly is a non-goal.

[alexander-akait]

Agree about option, just want clarify what maybe we need to improve somewhere API so that such things could be achieved easily

[thorn0]

By welcoming forks and providing a flexible plugin API, Prettier goes way further than what opinionated tools usually do. Contrast that with dartfmt's approach, for example.