Kinda unpredictable formatting of very long lines

[0xEAB]

I incidentally managed to write some code that would actually look good after applying dfmt :slightly_smiling_face: Well, then I extended it...

3 conditions - totally fine

bool someFunction()
{
    static if (scanProcedure != ScanProcedure.borderRightOnly
            && scanProcedure != ScanProcedure.cornerBottomRightOnly
            && scanProcedure != ScanProcedure.cornerTopRightOnly)
    {
        // ...

so adding a 4th one shouldn't hurt, should it?

bool someFunction()
{
    static if (scanProcedure != ScanProcedure.borderRightOnly && scanProcedure != ScanProcedure.cornerBottomRightOnly
            && scanProcedure != ScanProcedure.cornerTopRightOnly
            && scanProcedure != ScanProcedure.cornersRightOnly)
    {
        // ...

Conclusion

I'm aware that in consideration of the up to 120 chars rule, the second one is fine. The question might be rather: why does it split the conditions into 3 lines on example one? Again, I don't think it's bad that it does so, but it's just inconsistent behavior.

Nevertheless, it's confusing (and also disappointing in this special case) that adding a new condition (at the end) can twist the formatting of the previous code.

[0xEAB]

What does that mean in practice?

 {
     static if (scanProcedure != ScanProcedure.borderRightOnly
             && scanProcedure != ScanProcedure.cornerBottomRightOnly
-            && scanProcedure != ScanProcedure.cornerTopRightOnly)
+            && scanProcedure != ScanProcedure.cornerTopRightOnly
+            && scanProcedure != ScanProcedure.cornersRightOnly)
     {
         // ...

If someone blindly commits something similar to the example above (since one wouldn't expect yet another line to cause a quite different formatting), the next one applying dfmt can expect a surprise.