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.