New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Placing operators at the beginning of lines #3806
Comments
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 |
My expected behavior, if we’re going to change this: var a =
"123354535435"
+ "2342423153"; |
It'd be awesome if logical operators were included as well. Placing |
Is there any traction on this? At the very least when using |
@ryanwoodcox Prettier doesn't read any ESLint configuration |
@duailibe So what is the point of the |
@ryanwoodcox I think it's pretty clear already in prettier-eslint's README and (assuming you're talking about VSCode) in prettier-vscode README |
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!) |
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 ? |
@salonnlee We recommend turning off all linter rules that conflict with Prettier. See https://prettier.io/docs/en/eslint.html |
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. |
@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! |
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 |
I hope something will happen with this. Our team is using @btmills/prettier branch now but that has stopped us from using pretty-quick. |
Please reconsider this (and bring it in line with the way ternary operators are formatted).
|
The thing that bugs me most is what @aikeru pointed out: it's inconsistent with how ternary is currently formatted.
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;
} |
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. |
@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? :( |
That was the rationale for closing #5108. We don’t want to make upgrades too difficult and noisy for our users. |
A default-off option would be fully backwards compatible, right? |
Yes, but we try to avoid adding options since they make the code harder to test: https://prettier.io/docs/en/option-philosophy.html |
What about implementing this as a major version bump? |
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). |
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). |
@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.
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 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:
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. |
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.
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...
...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)?
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:
|
let's have it configurable at least |
If its configurable, then there will be no discussions anymore, as everyone can have their own way. |
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 |
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,
Please read the rest of the linked page for the "why" behind this rationale. |
@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). |
They're a good representative of people using your software, who have been requesting this since almost 5 years. |
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? |
@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. |
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 |
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: |
@joshlongerbeam Great! Do we know when we will get the official support for this issue? |
I agree with this thing. It's not just about personal preferences, but how operator placement affects:
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:
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. |
Is there a plugin that solves this issue? |
I'd just like to add my own experience, because I don't think I'm alone in this.
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. |
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 |
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. |
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 =/ |
Prettier 1.10.2
Playground link
# Options (if any): --print-width=22 --tab-width=4
Input:
Output:
Expected behavior:
The text was updated successfully, but these errors were encountered: