Break before operator on expression bodied methods and variable declarations.

[belav]

I think we should consider breaking before the operator for the following statements.

public void Serialize(ReadOnlySpan<byte> value)
    => InternalSerialize(Encoding.Utf8.GetString(value));
    
var someReallyLongName
    = "someReallyLongValueThatBreaks11111111111111111111111111111111";

As compared to

public void Serialize(ReadOnlySpan<byte> value) =>
    InternalSerialize(Encoding.Utf8.GetString(value));
    
var someReallyLongName =
    "someReallyLongValueThatBreaks11111111111111111111111111111111";

[respel]

Both look OK to me visually. Also, prettier uses the latter.

Do you have a concrete case in mind where we can benefit from using the former?

[belav]

There are readability arguments for breaking before the operator
https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator
There is also a lot of discussion about it here, although some differing opinions on if the break should happen before or after the =
prettier/prettier#3806

If you run into this type of a statement, it seems a little weird to have the = and the + aligned.

var someLongName
    = "someReallyLongValueThatBreaks11111111111111111111111111111111"
    + "someOtherReallyLongValue"
    + "someOtherReallyLongValue";

which could probably be solved by indenting

var someLongName
    = "someReallyLongValueThatBreaks11111111111111111111111111111111"
        + "someOtherReallyLongValue"
        + "someOtherReallyLongValue";

I did have a chance to discuss this with coworkers today, and they liked the idea of breaking before = and =>

[shocklateboy92]

Don't have a super strong preference, but I'm curious how you'd handle expression bodied lambdas like:

someLongAssObject.SomeLongAssFunction((someLongAssArg, someLongerAsserArg) => someLongAssArg.SomeLongAssMethod(someLongerAsserArg.SomeLongAssProperty))

[respel]

@belav Interesting articles.

There's one small catch though. In the links you gave, they are only talking about arithmetic and boolean operators, not assignment. Same goes for black.

[martindisch]

I tested a change that should do this for expression-bodied methods in #1693. I'm not fully convinced that the implementation holds up for all scenarios if you look at the tests and am happy to close it again. Feel free to use the PR in support of the discussion here and change it as you see fit.