IDE0055 fights against vertical alignment

[stephentoub]

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

Steps to Reproduce:

using System;

class Program
{
    static void Main() { }
}

[Flags]
public enum CompositionOptions
{
    Default                  = 0x0000,
    DisableSilentRejection   = 0x0001,
    IsThreadSafe             = 0x0002,
    ExportCompositionService = 0x0004
}

Ensure csharp_space_around_declaration_statements is set to do_not_ignore, then run the offered IDE0055.

Expected Behavior: IDE0055 isn't offered because there's a discernable vertical alignment being employed here.

Actual Behavior: It reformats it to:

[Flags]
public enum CompositionOptions
{
    Default = 0x0000,
    DisableSilentRejection = 0x0001,
    IsThreadSafe = 0x0002,
    ExportCompositionService = 0x0004
}

This can be avoided by setting csharp_space_around_declaration_statements to ignore, but then that negatively impacts the rest of the cases that would benefit from it, e.g. a normal declaration like:

int foo   = 17;

accidentally having a few undesired spaces.

We have a non-trivial amount of such vertical alignment across corelib and corefx, and in my opinion (and obviously in the opinion of the developers that independently authored each case) it helped readability. I don't want to further hamper readability by surrounding each and every such case with #pragma warning disable IDE0055, which just means we won't enable IDE0055.

[sharwell]

Related to (but not quite a duplicate of) #28729 and #36859

[ryzngard]

@stephentoub would this be required to work for fields as well? We're debating various designs and more use cases for styling like this will help us understand an approach moving forward.

[stephentoub]

would this be required to work for fields as well?

Ideally, yes.

[SquidPony]

Just ran into this today when importing code from another project and echo that it would be very very nice to be able to mark something like "x or more lines' vertical aligned ignore" in the options.

I usually see this with at least 3 lines in a row, but user configurable is probably best for something like this.

[levicki]

In Visual Studio 2019 version 16.5.4 with Keep Tabs enabled, Use Adaptive Formatting disabled, and editor indicator set to TABS, in .cs code file the editor is replacing tabs with spaces when writing new code (member variables in the class) such as below:

namespace DownloadStation
{
    public class DownloadTask
    {
        string  Name;
        string  Status;
        string  PercentDone;
        string  Size;
        string  Downloaded;
        string  Remaining;
        string  Speed;
        string  Seeders;
        string  Leechers;
    }
}

The tab typed between string and variable name is entered as two space characters.

If you replace them manually with tabs, then IDE0055 is issued for each line and it offers to "fix formatting" for each of those lines by again replacing tabs with spaces.

It is one thing to try to be helpful, but this is turning into total madness, because you are actively disregarding user input, ignoring configuration, and undoing work.

Moreover, trying to configure IDE0055 diagnostic to None from the editor does absolutely nothing -- it doesn't create per project .editorconfig file with the entry, nor it updates the global .editorconfig in the root of Visual Studio projects folder.

I am sure I am not the only one who would really appreciate if you all stopped messing around with Visual Studio editor and made it reliable again so we can be confident that what we typed actually ends up in the code file.

Finally, I heard about "premature code optimization" numerous times, and every time the conclusion was "don't do it, it's bad", but what about "premature code diagnostics" you are now doing?

Why is diagnosing unfinished code considered good practice if optimizing unfinished code isn't?

[sharwell]

@levicki The case you are hitting is #24031. See https://github.com/dotnet/roslyn/issues/24031#issuecomment-444067640 for more information on adding an option for this.

[jez9999]

I'd like this too.

[lonix1]

More cases from my issue #51389:

a    = foo;
bc   = 123;
some = thing;

static int Foo(int x, int y) => (x, y) switch {
  (    0,     0) => 0,
  (int i,     0) => 11,
  (int i, int j) => i + j,
};

if (foo == null)       throw new ArgumentNullException(nameof(foo));
if (foo == wrongValue) throw new ArgumentException(nameof(foo));
if (qux == 42)         throw new ArgumentOutOfRangeException(nameof(qux));

switch (i) {
  case 0:      foo(); break;
  case 1:      bar(); break;
  case 424242: baz(); break;
  case XYZ:    return;
  default:     throw new InvalidOperationException();
}

     if (true)      foo();
else if (false)     bar();
else if (something) baz();
else                qux();

[sharwell]

@lonix1 only the first item you listed is a duplicate of this issue. The rest should be filed separately or they are likely to drop off the radar once this issue is closed.

[lonix1]

@sharwell Sorry... I've reopened #51389

[levicki]

@levicki The case you are hitting is #24031. See #24031 (comment) for more information on adding an option for this.

Just a kind reminder that the issue you referred me to exactly one year and 3 days ago is still unsolved just like this one, and that people using TABs are still fighting with Visual Studio editor converting them to spaces and asking us to fix our formatting.

[CyrusNajmabadi]

@levicki we still do not have a design or approach figured out to solve these issues. Sorry!

[levicki]

@CyrusNajmabadi, @sharwell Is there any way for Microsoft developers to give some priority to this issue? Or is every single one of you hating developers who prefer to use TABs that much? Given that these kinds of issues were introduced 6 years ago with Visual Studio 2015 I am beginning to think it's the latter.

Having this in my (one and only, marked as root) .editorconfig does absolutely nothing:

# IDE0055: Fix formatting
dotnet_diagnostic.IDE0055.severity = none

How can I suppress the Fix Formatting option shown in the screenshot above?

I don't want it offered at all, ever.

My formatting is OK, it's Visual Studio editor who is retarded and keeps fighting my coding style.

[sharwell]

Or is every single one of you hating developers who prefer to use TABs that much?

This issue is completely unrelated to the use of tabs. If you are having a problem with tabs specifically, it is likely filed under a separate issue (based on the example, I'm guessing you are looking for #24031).

Having this in my (one and only, marked as root) .editorconfig does absolutely nothing:

# IDE0055: Fix formatting
dotnet_diagnostic.IDE0055.severity = none

This will work as long as the .editorconfig is in the same folder (or a parent folder) of the source file, no other .editorconfig files are taking precedence, and there are no syntax errors in the .editorconfig that prevent it from parsing correctly. If it's not working, you can use the Report a Problem tool for us to investigate using a build log.

How can I suppress the Fix Formatting option shown in the screenshot above?

You can disable IDE0055 in a .globalconfig instead of a .editorconfig if you want it to apply to the entire project without taking file paths into consideration.

[lonix1]

@sharwell I didn't know about .globalconfig, thank you! I assume it has to be in the project root? And it will override any .editorconfig files in the root or subdirectories?

[sharwell]

I didn't know about .globalconfig, thank you! I assume it has to be in the project root?

If you place it in the project root with this name, it will be included automatically. You can also add it to the build from a different location using customized build logic, which is what Roslyn does here (this works for .globalconfig because it doesn't rely on file system paths, but will not work for .editorconfig):

https://github.com/dotnet/roslyn/blob/c5df906949df1fd129103e857ffd334a7c831303/eng/targets/Imports.targets#L103-L111

And it will override any .editorconfig files in the root or subdirectories?

I believe that if you define the same option in .globalconfig and a .editorconfig, the .editorconfig will win.

[levicki]

This issue is completely unrelated to the use of tabs.

I use tabs for vertical alignment, and IDE0055 shows up offering me to "fix it" even when I disabled it. How is that not related to "IDE0055 fights against vertical alignment"?

If you are having a problem with tabs specifically, it is likely filed under a separate issue (based on the example, I'm guessing you are looking for #24031).

Thanks to Microsoft developers ignoring every "TABs replaced with spaces" issue reported ever since VS 2015 came out be it in Visual Studio Community or now here on GitHub (because let's face it they think they fixed formatting for everyone just because it aligns with their personal preference), nobody is able to navigate the rat's maze of issues with similar titles which are possibly pertaining to different areas of the Visual Studio code, but in reality all have a common denominator -- TABs are replaced with spaces when they shouldn't be.

6 years and counting we aren't any closer to a solution -- all we get is "closed due to lack of activity", "needs triage", "needs proposal", "we need more examples", "we can't change that because it might break something" or "that's unrelated, open another issue" when all we want is to have TABs remain TABs.

This will work as long as the .editorconfig is in the same folder (or a parent folder) of the source file, no other .editorconfig files are taking precedence, and there are no syntax errors in the .editorconfig that prevent it from parsing correctly. If it's not working, you can use the Report a Problem tool for us to investigate using a build log.

My one and only .editorconfig with root = true line in it is in C:\WORK\Projects, and all my projects are in folders below that one. Not a single project contains any project-specific editor settings because I like consistency.

As for the syntax error theory, I can't but wonder what kind of parser you would need to use for .editorconfig when it can't even process valid entries in it if there is a single error, let alone log the error or notify the user about it?

It must have been written by an intern and never seen any testing / QA, or someone senior would hopefully point out that failing to parse a configuration file for the most central function of an IDE should not default to silent fail.

Look, this is pointless. I apologize for wasting your time -- you obviously aren't interested in fixing this or any other issues related to TAB processing in C# or C++ formatter because if you were, it wouldn't have taken 3 years of begging to have absolutely no progress to show on any of them.

Why don't you just close them all with WONTFIX so that we all know where we stand?

[CyrusNajmabadi]

I use tabs for vertical alignment, and IDE0055 shows up offering me to "fix it" even when I disabled it. How is that not related to "IDE0055 fights against vertical alignment"?

Sam was pointing out this is unrelated to in specific. You'd get the same issue if you used spaces.

[CyrusNajmabadi]

Thanks to Microsoft developers ignoring every "TABs replaced with spaces" issue reported ever since VS 2015 came out

We have not ignored it. We just don't have a good solution for these issues yet.

[CyrusNajmabadi]

when all we want is to have TABs remain TABs.

Note: we might be open to accepting a community PR here if one can be done that can supply that behavior while:

1. not regressing any desirable existing behavior
2. not introducing a lot of complexity to the implementation.

If you are interested in contributing here, please let me know and we can start brainstorming how this could potentially work out.

[CyrusNajmabadi]

or C++ formatter

NOte: the C++ formatter is entirely different implementation from a different team. Any issues there will need to be reported to them as any changes in roslyn will have zero effect on them.

[CyrusNajmabadi]

My one and only .editorconfig with root = true line in it is in C:\WORK\Projects, and all my projects are in folders below that one. Not a single project contains any project-specific editor settings because I like consistency.

@levicki can you follow the instructions given by sam to file an issue on this. We'd need to investigate the particular case you are reporting to see what's going on there. thanks!

[CyrusNajmabadi]

Why don't you just close them all with WONTFIX so that we all know where we stand?

"WONTFIX" is for things we will not fix. We are open to fixing this. It's just extremely challenging, esp. as we tend to find that any changes in this space can end up causing 'spooky action at a distance' that then breaks some other case that people have come to depend on. So we're naturally conservative here about any work that happens because we don't want hte cure to be worse than the disease.

it wouldn't have taken 3 years

FWIW, we have limited resources here, and we have literal years of work booked out in terms of delivering features, bug fixes, necessary performance changes, 64bit work, out of process work, debugger work, etc. etc. etc. We genuinely would like to fix anything and everything, but we are human and just cannot get to everything. Nor can we state that just because something is old that it must get priority. THere are far older things that are far less important, and there are far newer things that demand immediate attention.

That said, as i mentioned above, this is an open source project and we would welcome assistance here. As this seems to be something you are very passionate about, perhaps it would be higher in your priority list than we've been able to make it for our priority list? If so, please let us know. Thanks!

[levicki]

We have not ignored it. We just don't have a good solution for these issues yet.

It's been 6 years since VS 2015 introduced this problem for some users (and solved it for others including you).

not regressing any desirable existing behavior

How would having a setting that allows vertical alignment of variables using tabs and having said setting OFF by default cause any regression or change in desired behavior? We just want a god damn option, we don't want to force anything on anyone else like you did to us for the past 6 years.

If you are interested in contributing here, please let me know and we can start brainstorming how this could potentially work out.

If I wasn't interested I wouldn't still be here after all this time. I already answered some questions and provided some rationalizations for some cases of alignment using TABs in the issue #24031 in response to @jmarolf and @sharwell and so far it led us nowhere.

If you let me know exactly what you expect from me and how I can help you to untie this Gordian Knot you are supposedly chewing on for so long I'd be glad to do as you request.

can you follow the instructions given by sam to file an issue on this. We'd need to investigate the particular case you are reporting to see what's going on there. thanks!

As a matter of fact, after I updated from 16.11.4 to 16.11.5 today, now IDE0051 is also not silenced anymore, even though I have it in the .editorconfig:

So either is my .editorconfig totally corrupted (to me it doesn't appear to be so, but feel free to inspect it as I attached it below), or your .editorconfig parser is totally broken and you keep introducing further regressions with updates.

We are open to fixing this. It's just extremely challenging

When something is extremely challenging people usually devote more resources to fixing it, not sit on it for so long and complain how it's complex. This issue has been in the queue for 2 years, #24031 was in the queue for 3 years, but the problem with TAB alignment is there for 6 years. There were countless reports on Visual Studio Communities which went unanswered and ultimately closed since 2015, and if you search this repo there are at least half a dozen of issues open on the subject.

Please don't tell me a single senior developer in your company couldn't fix TAB alignment in that time span (2, 3, or 6 years) if they were actually assigned to do it.

FWIW, we have limited resources here

You are making it sound like Microsoft is a poor mom-and-pop dev shop barely making ends meet, not a 2+ trillion corporation with global presence which rakes in billions in profits from subscriptions. Why your project managers do not ask for and hire more developers if you have such a huge backlog?

Nor can we state that just because something is old that it must get priority.

So if you worked in ER and you received a patient with a cut on his arm who needs two stitches to stop the bleeding he would bleed out to death, because you cannot get around to doing it since there will always be something more urgent to do? Got it.

That said, as i mentioned above, this is an open source project and we would welcome assistance here.

Roslyn may be an open-source project, but you included it as a critical and unavoidable part of a closed-source application (and broke TAB alignment for us in the process when you added it).

That application (Visual Studio) comes with a hefty recurring subscription fee, are you seriously suggesting that after paying for a license we should also pick up the mantle and write code for you, especially after ignoring all of our pleas for so long?

I must admit I am baffled by your request.

But then again, maybe this open-sourcing of Visual Studio and Windows components is just a new form of "privatize the profits, socialize the losses"?

Apologies for being cynical, but it is really hard seeing it any other way after so much time has passed.

editorconfig.txt

[CyrusNajmabadi]

How would having a setting that allows vertical alignment of variables using tabs and having said setting OFF by default cause any regression or change in desired behavior?

It might not. We'd have to examine the pr and test thoroughly to validate. As I said, we would appreciate help here.

One challenge is how the formatter is designed. The other is how it's handles trivia (things like whitespace). There isn't a good place that I've found to include the concept of 'tabs' there.

Vertical alignment might be possible, but adjust very tricky due to how all the other rules combine. If you are able to make it work we'd be happy to look!

[CyrusNajmabadi]

If you let me know exactly what you expect from me and how I can help you to untie this Gordian Knot you are supposedly chewing on for so long I'd be glad to do as you request.

I outlined it before, but a safe, well-tested pr that addresses the issue with complexity self-contained. We would not want something that carries high risk of impacting existing scenarios. Thanks!

[levicki]

If you are able to make it work we'd be happy to look!

If you who knows the ins and outs of your own code cannot make it work, what chance do I have?

Also I am just trying to do my own work IN Visual Studio. If I wanted to work ON Visual Studio, I'd apply for a job at Microsoft.

[CyrusNajmabadi]

So either is my .editorconfig totally corrupted (to me it doesn't appear to be so, but feel free to inspect it as I attached it below), or your .editorconfig parser is totally broken and you keep introducing further regressions with updates.

Can you please open another issue on this. I can route the appropriate engineers to look at that. Thanks!

[CyrusNajmabadi]

When something is extremely challenging people usually devote more resources to fixing it,

Unfortunately, we cannot. There are far too many high pri items that we have had to focus on over the years. As I stated above, we are literally booked out with man years of work ahead of us. I myself have been working primarily on only performance work as that has been seriously pressing for years.

As before, length of time is not the question here. It's how important this is against all the other work we have. In this case, while this is unfortunate, there is a ton of other stuff that keeps being more important that we have to fix it work on.

[CyrusNajmabadi]

there will always be something more urgent to do? Got it.

Correct. Using your analogy, if critical patients keep coming in, then non-critical cases so keep getting pushed out.

[CyrusNajmabadi]

If you who knows the ins and outs of your own code cannot make it work, what chance do I have?

As I said, I don't have the time here to address this. However, as you seen to be very passionate, I thought you might be open to helping us here :-). We would very much appreciate it and we've worked with dozens of contributors to improve the problem and to help them solve things for both themselves and everyone who uses the product.

That's the beauty of open source. Even if we don't have the time to work in this, that doesn't mean it can't be improved. Other people can contribute as well if it is a really important issue for them! :-)

[sharwell]

It's been 6 years since VS 2015 introduced this problem for some users (and solved it for others including you).

There are two main issues at hand:

1. I used primarily hard tabs from ~2001 to ~2015, and one of my primary complaints was IDEs always made the mistake of allowing a hard tab to appear to the right of a visible character, which broke the use of variable-width tabs. When Visual Studio 2015 shipped, this issue was finally fixed for me (not at my request and I didn't have anything to do with the implementation; I first joined Microsoft more than a year later). I'm not the only hard-tabs user in this category, which means the current behavior is not uniformly undesirable.
2. The system used for the current formatter was implemented with a deeply ingrained assumption that the current handling of tabs/spaces was the only handling that would ever need to be allowed. Unraveling that to try and add an option revealed orders of magnitude more complexity than expected, so it just didn't seem realistic to try and make both ways work.

We hear about the same amount of complaints on the new behavior that we had on the old, so if we just revert it to the pre-2015 behavior the only outcome we see is doing a lot of work just so a different group of users complains to us once a year or so.

[CyrusNajmabadi]

Apologies for being cynical, but it is really hard seeing it any other way after so much time has passed.

I am simply being honest. We have always told you the truth here. The reality of the situation is that we will never have the time or team man power to address every request or get to every issue. We can try, but at far many other things, if far higher importance, keep coming up.

This is why the issue backlog for roslyn is> 5000 items. And why you'll find issues a decade old (and older in our internal issue dbs). There are tons of requests and tons of customers asking us for tons of different things.

So if your only choice is to wait on us, then it's always possible that the thing you want may take a long time to get. I know that can suck, but I can't change the amount of work I can get through in a day :-(

However, being open source, we really do take contributions and we really do think it's a great way for individuals to step in and get the benefits they want without waiting on the teams' schedule and priorities (which are never going to align with every single customer).

We're open source because we get that we'll never be able to be an things to all users. But when we're not, users can step in and themselves make things better! :-)

Lmk if interested. Also, happy to take this discussion to gitter or discord.

[jez9999]

Ahh.... this one still aint fixed yet. Ah well. By the way, @levicki , I wrap my enums in the following to suppress this warning when doing vertical alignment to the right:

#pragma warning disable format
...
#pragma warning restore format

Hopefully that still works, at least.

[lonix1]

@jez9999 Didn't know about that trick, thanks! When I need to, I disable individual analysers. Am I right in assuming your code disables all of them at once? (I tried to RTFM, but couldn't find docs for this specific approach.)

[jez9999]

I believe it just disables code formatting warnings. See https://github.com/dotnet/roslyn/pull/38627

[levicki]

@jez9999 Thanks for the tip, I really appreciate it. However, I am not going to litter my code with pragmas -- that's like saving your IDE settings in the code itself, and to me that's a ridiculous approach to solving the underlying problems with the IDE.

[jez9999]

Seems like a formatter extension could deal with this bug if/when the following gets introduced: https://github.com/dotnet/roslyn/issues/31691