IDE0055 doesn't provide any control for semicolon positioning on while/for statements

[stephentoub]

Version Used:
3.3.0-beta3-19415-01+f5ba9f2c61a2fe853dc4913888d40df221539147

Steps to Reproduce:

using System;

class Program
{
    static void Main()
    {
        Console.WriteLine("starting");
        while (!Ready);
        Console.WriteLine("done");
    }

    private static bool Ready => true;
}

Expected Behavior:
I should be able to configure my settings such that this code isn't changed by IDE0055.

Actual Behavior:
IDE0055 (formatting fixes in general) forces this to:

using System;

class Program
{
    static void Main()
    {
        Console.WriteLine("starting");
        while (!Ready) ;
        Console.WriteLine("done");
    }

    private static bool Ready => true;
}

which just looks wrong compared to the positioning of the semicolons in the other statements.

[sharwell]

This seems like a bug in the current formatter handling of semicolons, but we'll go over it in design review to confirm.

[CyrusNajmabadi]

IIRC, this was intentional (though the decision was made like 10+ years ago). the idea was "we should call attention here to make it clear that this is an empty-while". if the ; abuts the ) it's easier ot miss and users may think the next line is what is being looped.

That said, nothing is sacrosanct. We could change our defaults here. Or create a set of toub_formatting rules :)

[stephentoub]

Or create a set of toub_formatting rules :)

If this ends up being closed as by-design, let's absolutely do that! Long live toub_formatting rules. 😉

[CyrusNajmabadi]

Note: we do have an open goal of allowing extensible formatting. That way, at the end of the day, if there is something very particular for your group, you can express it. That said, for at least some of your issues (like aligning variable decls), i think those are so common and widespread they should be considered as options.

[stephentoub]

Also, I should note that in general I'm trying to respect the style of the codebase that's already there. In this case, a quick search across corefx shows ~250 uses of for (...); and ~15 uses of for (...) ; (I'm guessing the latter being cases where the IDE asserted its will 😉).

[sharwell]

Design review conclusion:

• The design may have been on purpose, with a goal of highlighting potentially-unexpected empty control flow blocks

• We should create a new analyzer for the problematic cases instead of relying on the formatter

  1. Report a diagnostic if an indented statement follows a looping construct with an empty child statement, such as:

     if (condition);
       statement;

     ➡️ This is already covered by the formatting analyzer.

  2. Report a diagnostic if a block follows a looping construct with an empty child statement, such as:

     if (condition);
     {
     }

     ➡️ This will need a new analyzer.

• We should update the formatter to no longer place the space between ) and ;. Existing code will be updated to the new style the next time Format Document is run. This is a rare case, so we are not expecting significant push-back for the formatting change.