-
-
Notifications
You must be signed in to change notification settings - Fork 91
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
Wrapping arithmetic expressions not stacked/chopped down #547
Comments
Curiously, here is a case that appears to behave as expected: class E
{
void v()
{
int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
int bbbbbbbbbbbbbbbbbbbbbb;
int cccccccccccccccccccccccccccc;
int a =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
- bbbbbbbbbbbbbbbbbbbbbb
- cccccccccccccccccccccccccccc;
}
} |
This had to do with some logic not taking into account that operators with the same precedence should be aligned. It was only aligning identical operators. I could see the argument for making invocations and binary expressions consistent. CSharpier is consistent with prettier in that invocations and binary expressions are printed differently. That would be a much bigger change. |
Doesn't that mean */ still would not wrap? |
* Ensure that operators that have the same precedence are aligned. closes #547 * Fixing edge case Co-authored-by: Lasath Fernando <devel@lasath.org>
This change affected */ in the same way. class C
{
void v()
{
var e =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa * bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
/ ccccccccccccccccccccccccccccccccccccccccc
* ddddddddddddddddddddddddddddddddddddddddd;
}
} Now will format as class C
{
void v()
{
var e =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
* bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
/ ccccccccccccccccccccccccccccccccccccccccc
* ddddddddddddddddddddddddddddddddddddddddd;
}
} |
Verified in CSharpier 0.11.1 and 0.13.0.
If an arithmetic expression extends beyond the line limit and induces wrapping onto at least 3 lines (+2 breaks), the operands are not all stacked (JetBrains calls this "chop down").
That is, I get
where I expected
InvocationExpression does not have this peculiarity. Instead, they leave the invocation target on the assignment line and chop down the expression:
(I might argue that the two constructs are mutually inconsistent and that that idiosyncracy arguably constitutes its own bug, with a personal preference for the former, but that's a less jarring matter).
The text was updated successfully, but these errors were encountered: