Roslyn: An option controlling the indentation of code within a #region block should be provided.

[tannergooding]

Currently code within a #region block gets formatted as follows:

public class ExampleClass
{
    #region Methods
    public void ExampleMethod()
    {
    }
    #endregion
}

An option should be provided so that code within a #region block can be indented by one level by default. Doing so would cause the above code to become:

public class ExampleClass
{
    #region Methods
        public void ExampleMethod()
        {
        }
    #endregion
}

[sharwell]

The indentation behavior of #region has remained the same for many Visual Studio releases. During today's design review, the team generally felt that uniformity provided by this uniformity is an asset to the ecosystem, and we would not want to introduce a configuration item related to this outside of emperical evidence showing significant use of an alternative formatting.

[Geri-Borbas]

Err, you mean this will be never implemented?

The demand is real:
https://twitter.com/_eppz/status/887687782684139525
https://github.com/OmniSharp/omnisharp-vscode/issues/1556

[tannergooding]

Yeah, I believe this (like most formatting issues) is one of those cases where if you do just a little bit of digging, you will see a number of requests for it over the years (much like was the case for https://github.com/dotnet/roslyn/issues/12306)

[CyrusNajmabadi]

@tannergooding I don't doubt the desire for it exists from some. The questions are if that group is large enough, and if providing the option provide enough value over the negative externalities it introduces.

I'm with @sharwell that the uniformity is actually a benefit to the ecosystem at large.

--

It's a similar assessment process to language features. They start net-negative, and have to provide enough to push them over that line. In this case, i personally don't think that is the case.

[Geri-Borbas]

Thanks for getting back!

@tannergooding @sharwell @CyrusNajmabadi I just don't really get why you make #region an exception. I mean there are like 1000+ code formatting option existing right now that ruins uniformity already every day.

[CyrusNajmabadi]

I just don't really get why you make #region an exception.

There was no exception made :). There are literally dozens of syntactic features that have no formatting/indentation customization offered for them. preprocessor-directives are simply in that group as well.

The goal was not to provide customization for every bit of whitespace trivia possible in the language. The goal was to meet the needs of the vast majority of hte userbase. Even now, with the options we have shipped, we find that almost all settings are never changed from the default. So the vast majority of the ecosystem uses teh same settings, except for a tiny handful of hugely relevant options (i.e. what style bracing do you want).

[sharwell]

I mean there are like 1000+ code formatting option existing right now that ruins uniformity already every day.

Hindsight is 20/20. Knowing what I know today, I would have made the same argument for a majority of the existing formatting options. But now people are using them so it's a different story.

[CyrusNajmabadi]

@sharwell Probably worth going over telemetry with kendra. IIRC, there are some options with 0 usages in the wild. They would likely be candidates for removal. We have precedence for removing things in the past when we discovered there was no usage.

[Geri-Borbas]

Oh no, please stop, you are killing more formatting options? 😆

[CyrusNajmabadi]

Options that aren't used are just a maintenance tax on the product. The formatting engine is already massive complex. So removing unneeded options helps with the agility of hte product. :)

[Geri-Borbas]

Sure, in the everydays I'm also a big fan of code removal. It always an instant improvement.

[Geri-Borbas]

However, I'm pretty sure that -1 indented #region directives makes code much more readable. I'm all into code readability (take this Visual Studio Code color scheme concept used by 60K as a proof), as it is said to be more often read than written, and I really think this could improve a whole lot.

Make it -1 by default then, so the ecosystem remains consistent, and the code more readable. 😄

[CyrusNajmabadi]

Feedback definitely noted :)

[MarqueIV]

I have been yelling about this very thing for years. It's so frustrating that when you expand regions, the code is at the same level. There is concrete proof that readability is affected. It's the same rule they use in advertising. Whitespace with blurred eyes. Try this little test and you'll see why you need this.

Step 1: Open a large code file with several regions, preferably those that are right next to each other
Step 2: Expand all those regions
Step 3: Blur your eyes and look at the code

Can you clearly see where one region ends and the others begin? No, you can't because with them at the same level as the code, everything is at the same level as the code so there's no demarcation.

Additionally, any argument around 'But you can just add blank lines between them' or similar misses the point because that means you have something to break apart the code (regions) and something else to break apart the code (multiple blank lines) so then why have regions in the first place?

Regions are code organization features. Their entire point is to organize the code. If, by the nature of being expanded, you lose that organization, then you've failed at your task. Heck... what VB.NET does is better, and even that's not great. Regions are all hard-left in the editor. But at least being hard-left, they still pass the whitespace-blur capability.

Yes, I understand the argument that there are a lot of options in the formatter already, and yes, I would agree a lot of them are kind of useless, but this one is something that is actively making the region feature less useful. For instance, I have gotten into many debates about the usefulness of regions (i.e. read Coding Horror's blog on regions) and I found most people don't like the what that's being grouped in that argument. When I show them a different grouping strategy, all of a sudden, they say 'Wow! That's a really great way to use regions!" and without fail, they always come back and say '...but how do I keep my code indented under it?' and I have to always reply 'You can't until Microsoft addresses that.'

So, again, regions being part of the code structure which are by-design meant to show grouping, if they fail in that aspect when in their expanded state, then that should be cause to reconsider the 'won't-fix' stance. It's an oversight in the original design. I'd actually bet the cost of VS that the consistency argument won't actually hold up anyway because if you took a poll of those who love regions, I bet the vast majority of them would actually prefer the indented version instead of the shove-it-all-to-the-same-level approach that's there now.

Oh... and for the record, I would happily pay additional money for this feature as it would save all the time I have to undo you messing up my regions! The time alone would easily cover the cost.

One final word... if a feature is actively making your users frustrated, and in the case of large and/or many files, actively angry by trouncing on their intent, shouldn't that be considered over consistency?

Please reconsider.

Mark

[CyrusNajmabadi]

@MarqueIV You'll likely be able to write your own formatter rule for this as part of https://github.com/dotnet/roslyn/issues/31691

Oh... and for the record, I would happily pay additional money for this feature as it would save all the time I have to undo you messing up my regions! The time alone would easily cover the cost.

Go on... :)

[sharwell]

I'm going to reopen this as Blocked on #31691 so the feature request is included in the consideration for the extensibility design.

[MarqueIV]

@MarqueIV You'll likely be able to write your own formatter rule for this as part of #31691

Oh... and for the record, I would happily pay additional money for this feature as it would save all the time I have to undo you messing up my regions! The time alone would easily cover the cost.

Go on... :)

I'm only half-kidding! If there was a paid add-on that gave me this (and I have loooooooked!!!) I'd happily plunk down $50 for that alone. Maybe even $100. Id be mad that I did, but I'd get over it. ;)

[bachowny]

Adding my vote for this. Please make it so that code within regions is indented and that this can be applied when formatting files.

[Hjorthmose]

Adding my vote for this as well!