Placing operators at the beginning of lines

[599316527]

Prettier 1.10.2
Playground link

# Options (if any):
--print-width=22
--tab-width=4

Input:

var a = '123354535435' + '2342423153';

Output:

var a =
    "123354535435" +
    "2342423153";

Expected behavior:

var a
    = "123354535435"
    + "2342423153";

[azz]

I don't think we should add an option for this, but just change the current behaviour. Put the operator on the left for arithmetic operations, but the other logical/binary operators should remain on the right.

https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator

[j-f1]

My expected behavior, if we’re going to change this:

var a =
    "123354535435"
    + "2342423153";

[ghost]

It'd be awesome if logical operators were included as well. Placing && or || at the start of lines rather than the end is very similar to trailing commas in that it produces cleaner diffs.

[ryanwoodcox]

Is there any traction on this? At the very least when using prettier-eslint with prettier.eslintIntegration to to true, the operator-linebreak option should be respected and it is not.

[duailibe]

@ryanwoodcox Prettier doesn't read any ESLint configuration

[ryanwoodcox]

@duailibe So what is the point of the prettier-eslint package and the prettier.eslintIntegration option?

[duailibe]

@ryanwoodcox I think it's pretty clear already in prettier-eslint's README and (assuming you're talking about VSCode) in prettier-vscode README

[trash]

Mayhap I'm beating a dead horse here but I think this should become a part of the opinionated standard. As commented earlier, there's a great argument for leading with operators for readability but I can't really find any arguments for why trailing operators would be better. It seems to objectively just be harder to parse.

Totally understand punting on this for not wanting to open an opinion-haver's ****storm but my guess would be that not many people are attached to this option so switching this in a v2 wouldn't cause a big hoopla.

(Either way, I've started using the wonderful @btmills fork!)

[salonnlee]

I've had this problem recently. There are conflicts when working with Prettier and ESLint to format code. May I ask if the problem has been solved ?

[lydell]

@salonnlee We recommend turning off all linter rules that conflict with Prettier. See https://prettier.io/docs/en/eslint.html

[salonnlee]

The problem is that our team shares one ESLint setting. I should delete Prettier and not somebody else delete ESLint. If I keep using Prettier, I will create conflict with other members.

That's why I agree to make "operator-linebreak" configurable.

[lydell]

@salonnlee I know what you mean, it's sad when you're forced to follow a an ESLint config or styleguide and the rest of the team isn't willing to use Prettier. One day you might be able to convince them, though! Until then, according to the ESLint documentation for operator-linebreak it supports autofix (at least partially) so you might be able to use prettier-eslint!

[btmills]

Though the pull request (#5108) was declined, I did end up taking the recommendation in the feedback there, and I just published a fork with this change as @btmills/prettier. (Disclaimer: it's for my own convenience, use at your own risk, etc.) If the decision ever changes and the maintainers want to make this change in Prettier itself, I'd welcome the chance to re-submit a PR!

[daliusd]

I hope something will happen with this. Our team is using @btmills/prettier branch now but that has stopped us from using pretty-quick.

[aikeru]

Please reconsider this (and bring it in line with the way ternary operators are formatted).

// Please do this - read vertically down :)
const foo = barValue
            && checkBazValue()
            && qux.isTrue()

// Please stop doing this - scan entire line :(
const foo = barValue &&
            checkBazValue() &&
            qux.isTrue()

[joshlongerbeam]

The thing that bugs me most is what @aikeru pointed out: it's inconsistent with how ternary is currently formatted.

Prettier 1.15.2 Updated for Prettier 2.5.1
Playground link

Input:

if (
  longVariableName === "this"
  || typeof otherLongVariableName !== "object"
  || evenLongerVariableName === "something else"
) {
  a =
    longerVariableName
    + tinyVarName
    + deeply.nested.variable
    - even.deeper.nested.variable;
  b =
    longVariableName === "this"
      ? a
      : longVariableName === "that"
      ? a + 1
      : longVariableName === "something else"
      ? a - 1
      : 0;
}

Output:

if (
  longVariableName === "this" ||
  typeof otherLongVariableName !== "object" ||
  evenLongerVariableName === "something else"
) {
  a =
    longerVariableName +
    tinyVarName +
    deeply.nested.variable -
    even.deeper.nested.variable;
  b =
    longVariableName === "this"
      ? a
      : longVariableName === "that"
      ? a + 1
      : longVariableName === "something else"
      ? a - 1
      : 0;
}

[j-f1]

Pointing that out makes the style make somewhat more sense, but I still think we shouldn’t change this since it changes a lot of printed code.

[aikeru]

@j-f1 From your comment, it seems that decisions are made w.r.t. changing prettier conventions based on how much existing code they might change. Am I misunderstanding something? :(
If this is correct, it is surprising to me.

[j-f1]

That was the rationale for closing #5108. We don’t want to make upgrades too difficult and noisy for our users.

[jleclanche]

A default-off option would be fully backwards compatible, right?

[j-f1]

Yes, but we try to avoid adding options since they make the code harder to test: https://prettier.io/docs/en/option-philosophy.html

[0az]

What about implementing this as a major version bump?

[daltonhildreth]

I agree with @trash, considering the virtually universal acceptance of this change within this issue (except from the project maintainers who seem somewhat unjustifiably worried about a backlash).

Were this marked as a major version bump as @0az suggests, any worry from changing many lines among projects is mitigated. Furthermore, common style guides like AirBnB already do this, so it might even appeal to some people who haven't already adopted Prettier.

Technically, this would be a complete benefit for being more consistent and readable, as many have noted. And besides that, Prettier should at least try to be consistent about its opinions rather than obstinate (and, as was strongly approved of in the issue to resist configuration, the items chosen should be consistent and look nice).

[Rycochet]

This is just a single data point after a google search which shows that in this particular project, people naturally tend to put binary operators at the end of lines. This was also true within the Facebook codebase when we made a lot of the early printing decisions. The goal from the beginning with Prettier was to generate code in the way people are doing it in practice.

Your google-fu is extremely lacking then...

This has been part of the C style formatting standards for decades (and JS/TS etc are C style languages) - https://www.gnu.org/prep/standards/html_node/Formatting.html - I'm even pretty sure that it was part of the original K&R book back in the late 70s (but don't have my copy any more to check).

[JanJakes]

@vjeux I'm sorry, but your post seems very misleading to me. You are presenting your personal preferences as if they were universal facts, and making generic statements that are simply not true.

but in practice, as far as I know, this is not the natural way people tend to write code

There was a lot of great discussion in this thread already, and I don't know what a generic statement supported with "as far as I know" contributes here, other than adding blur and making some people believe this might be the truth. Adding a single anecdotal case from a different programming language, I think, only creates more confusion:

This is just a trinodb/trino#8157 after a google search which shows that in this particular project, people naturally tend to put binary operators at the end of lines.

This is extremely misleading. It's not that hard to look at the standards in other programming languages (rather than refer to a single cherry-picked project). Doing so, we'll find the following:

• PHP: the PSR standards place operators at the beginning of lines.
• Rust: the native rust fmt places operators at the beginning of lines
• Java: the Oracle guidelines tell us to place operators at the beginning of lines
• Python: the PEP guidelines take no position, the most popular autoformatter places operators at the beginning of lines
• Swift: the Apple's swift-format places operators at the beginning of lines
• C/C++: the GNU guidelines place operators at the beginning of lines

The only popular language I know of that places operators at the end of the lines by default is Go (via go fmt).

I mean, really, it's not that hard to look up some facts. Let's not create a false impression that this change something that people are not doing in practice. It can hardly be any further from the reality.

[joshlongerbeam]

@vjeux,

Firstly, thank you so much for all the work you've done to get prettier to this state and for giving us more insight to the rationale for the hesitancy on this change. I would guess that the biggest frustration for many commenters on this issue has been the lack of feedback and transparency on this matter, as this was certainly my biggest qualm. I hope the amount of negative feedback you've received doesn't deter you from continuing to interact with this faction of the prettier community.

---

this is not the natural way people tend to write code

Ever since prettier, my natural way to write code has become "stub out as much of my thought as I can into one line before I lose my train of thought, then run prettier and go from there". With how easy it is to add a formatter to a dev's workflow, I'd imagine many people's natural way to write code is now "whatever the formatter chooses". Because of your and the rest of the prettier team's work, I trust the formatter to make my code worlds more readable without a second thought. But in terms of readability, this one issue sticks out like a sore thumb among an otherwise irreproachable tool.

So while it's probably true that...

The only people that come to the github repo are the ones that are not happy about one aspect and are going to find a way to change things.

...this doesn't automatically mean that the vast majority of people are happy about it or even have any opinion at all. Can you look at the earliest code examples in this thread, like this one with diagrams, and tell me this would not be a unanimous improvement in readability? Or perhaps you disagree with the notion that this is more consistent with how prettier handles other similar situations (e.g., ternary operators)?

---

We're going to hold off from making this change.

I can't say I'm not extremely discouraged, especially since we've all heard the song and dance of "we'll address this at the next major version" once already.

If you only address a single point I've made, let it be this:

• What sort of non-anecdotal evidence would it take for you to consider changing your mind instead of kicking the can down the road?

[seahindeniz]

It was planned for 3.0 last time I check. Do we have any news on this @fisker, @thorn0?

[iahmedgamal]

let's have it configurable at least

[gintsmurans]

If its configurable, then there will be no discussions anymore, as everyone can have their own way.

[magdalipka]

I added the option to configure this in #14475 . By default operators are placed at the end of line, but you can toggle placing them at the beginning with operatorPosition option. All previous tests passed, manual testing with operatorPosition toggled were also successful. I can write automatic tests and help - but I see no point in doing that if owners decide to reject it anyway.

[joshlongerbeam]

Please stop derailing this issue with the "add an option" suggestion (which has also been made much earlier in the issue history). As mentioned in the "option philosophy" of the prettier docs,

We have enough confidence to conclude that Prettier reached a point where the set of options should be “frozen”. Option requests aren’t accepted anymore.

Please note that as option requests are out of scope for Prettier, they will be closed without discussion.

Please read the rest of the linked page for the "why" behind this rationale.

[lucasbasquerotto]

@joshlongerbeam I agree that an option shouldn't be needed in this case and operators should be in the beginning of lines by default (when an expression has more than 1 line), but if the prettier team can't reach a consensus about where to place the operators (I don't know why, tough), then adding an option seems the most viable way to solve it, especially considering how many people are interested in this issue (it's the 2nd with most 👍, even considering closed issues, it's the 5th).

[TiredFalcon]

The other aspect to consider is that github issues on this repo are not representative of the overall population.

They're a good representative of people using your software, who have been requesting this since almost 5 years.

[YashSaxena9]

I came across this thread after facing the same problem. I want my operators to wrap at the start of the line. Is there any workaround or a promising solution in progress right now?

[alex12058]

@YashSaxena9 The btmills/prettier and @marketgridsys/prettier forks place operators at the beginning of the line. I maintain the latter one which applies a few more formatting styles that differ from prettier.

[idemax]

so no official support so far?

[GeorgeWL]

so no official support so far?

no official support, and a huge argument in comments because prettier refuse to allow new prettier options, despite demand for them from their userbase

[joshlongerbeam]

No official support yet, but it sounds like it's actually on the horizon shortly after they finish the release of version 3.0 (which is currently on alpha-12 and only awaiting a vscode issue).

Sources:

• comment on implementing experimental flags not having to wait for another major version bump
• comment about vscode being only remaining blocker (and following comments about this issue)

[JosipMuzic-KTO]

@joshlongerbeam Great!
I can see v3.0 is out now 😄

Do we know when we will get the official support for this issue?

[ryangatchalian912]

@vjeux I'm sorry, but your post seems very misleading to me. You are presenting your personal preferences as if they were universal facts, and making generic statements that are simply not true.

but in practice, as far as I know, this is not the natural way people tend to write code

There was a lot of great discussion in this thread already, and I don't know what a generic statement supported with "as far as I know" contributes here, other than adding blur and making some people believe this might be the truth. Adding a single anecdotal case from a different programming language, I think, only creates more confusion:

This is just a trinodb/trino#8157 after a google search which shows that in this particular project, people naturally tend to put binary operators at the end of lines.

This is extremely misleading. It's not that hard to look at the standards in other programming languages (rather than refer to a single cherry-picked project). Doing so, we'll find the following:

• PHP: the PSR standards place operators at the beginning of lines.
• Rust: the native rust fmt places operators at the beginning of lines
• Java: the Oracle guidelines tell us to place operators at the beginning of lines
• Python: the PEP guidelines take no position, the most popular autoformatter places operators at the beginning of lines
• Swift: the Apple's swift-format places operators at the beginning of lines
• C/C++: the GNU guidelines place operators at the beginning of lines

The only popular language I know of that places operators at the end of the lines by default is Go (via go fmt).

I mean, really, it's not that hard to look up some facts. Let's not create a false impression that this change something that people are not doing in practice. It can hardly be any further from the reality.

I agree with this thing. It's not just about personal preferences, but how operator placement affects:

1. Git diff reports: During code reviews
2. Code behavior: When adding or removing operands in a multi-line operation

If you worked with mathematicians or you have great math exposure, you would realize that multi-line equations are written with operators at the start of the line. Searching either" multi-line equations" or "elementary math addition" (i.e., your Grade 1 math) would show that this is the case.

This leads us to what code formatting is really made for. Code formatting is not made purely for aesthetic or preferential reasons, but for:

1. Reducing visual/cognitive overload, especially when doing code reviews
2. Making it more maintainable (related to REASON 1)
3. Minimizing coding mistakes
4. Applying good coding practices (related to REASON 3)
5. And most importantly, being consistent in your codes :-)

I've been using Prettier for 5+ years already and have already migrated to v3.0.0. Its opinionated output is fine, given the fact that JavaScript does not have a built-in formatter like Go and Rust do.

The Prettier team sometimes makes changes in formatting behavior. Hopefully, they consider examples from other languages, coding style guides, and mature JS projects instead of dismissing something due to hasty generalization.

Let's see how the maintainers will deal with this issue.

[seahindeniz]

Is there a plugin that solves this issue?

[bmslgpn]

I'd just like to add my own experience, because I don't think I'm alone in this.
I'm working on a relatively mature Java project with a very large java source code base. Line formatting has been done "by hand" from the start, but with certain rules that every developer tries to respect, in particular operators are always at the beginning of the line, the line length is 140 characters and indentation is 2 characters.

• Spotless Eclipse does not provide satisfactory line wrapping.
• Google-java-format has a line width of 100 characters, which is far too archaic.
• Palantir has an indentation of 4 non-configurable characters.
• Prettier is the candidate closest to our needs, with excellent line wrapping, good indentation and a configurable line width.

Unfortunately, the placement of Prettier's operators at the end of the line is a nogo for us.

If the aim of not changing the operator placement is to avoid a "breaking change", I see it a bit like the tradition of sacrificing a goat to the code god, we know it's not the right thing to do but as we've always done it, we keep on doing it.

If you really don't want to change the code formatting of existing projects, the only solution is to make it customisable. It was a design error in the first place, so there's nothing wrong with correcting it and making the change easier for everyone by adding this parameter. In the long term, this parameter can be removed and placing the operator at the beginning of the line will naturally become the only possible option.

The adoption of code formatters in IT projects could be much better if the tools were better adapted to everyone's needs. The google-java-formatter already meets the "no configuration possible" need, if people really wanted that, they'd take the Google formatter. Prettier could be the configurable alternative that everyone needs.

After that, it's your project, you do what you want, I just think it's a shame not to take up this niche.

EDIT: If I had to do this change, I would change the behaviour by default and would add a parameter "legacyOperatorPosition" (or something similar) for people wanting to stick with their current formatting.

[seahindeniz]

I agree. This is the only reason why most projects in my focus doesn't use prettier and all waits for this issue to be solved since the last 2 years

[rdecoito]

I'm still pretty shocked the default behavior is not changed yet after so long. I grant it is completely reasonable to resist the idea of adding an option for this, since that is expressly a stated goal of Prettier. This shouldn't be an option in the config.

However, the default behavior of Prettier's formatting can and should change according to best practices. That's not to say that we should strive to make everyone happy 100% of the time. Some people are going to be unhappy. But this seems like a no-brainer best practice, as affirmed by multiple other style guides across multiple languages. Breaking before operators is almost objectively the most readable option here. I cannot think of a single reason why you would want to put operators at the end of a line, given the earlier points about varying line width and the resulting visual alignment of logical elements.

I understand the desire to avoid breaking builds, but that's why we have major version releases. In fact, Prettier itself warns users in the documentation that it will change the way it prints code in each release. In the Install docs you can see this clearly:

To me, it seems that the maintainers of Prettier want to avoid changing old defaults, despite overwhelming community support (see thumb-ups above) and Prettier's own philosophy about how it's okay to change formatting rules across releases.

This is the kind of status-quo attitude that kills tools like this. I started using Prettier recently and I was genuinely taken aback by such a silly default behavior. It's not a good look.

At a bare minimum, Prettier should make a commitment one way or the other about whether this issue will be fixed, rather than being wishy-washy about it. At least that way I can make a decision about whether to abandon use of the tool or not.

[RodRich1991]

I know this have been oppend for a long time. But its sad to have to stop using such good tool like prettier for such limitations =/

[gitgdako]

Adding another thumbs up for changing this behaviour