Support enforcing "Code Style" in the IDE

[Pilchie]

• Roslyn Workspace APIs need to support per-file options (Code Style: Roslyn Workspace APIs need to support per-file options #7058)
• OptionSet API available at compiler layer for analyzer authors to use (Code Style: OptionSet API available at compiler layer for analyzer authors to use #7059)
• [Code Style] Give users more control over the visual treatments of each option [Code Style] Give users more control over the visual treatments of each option #13963
• Options can be populated from .editorconfig files (Add support for document specific analyzer options #3798)
• Coordinate with platform team about .editorconfig (Code Style: Coordinate with platform team about .editorconfig  #7061)
• CodeStyle Tools Options window: show correct and incorrect examples in the preview window. (CodeStyle Tools Options window: show correct and incorrect examples in the preview window. #13581)
• Analyzer + Code fix for use of var (Code Style: Analyzer + Code fix for use of var #7062)
• Analyzer + Code fix for member naming conventions (Code Style: Analyzer + Code fix for member naming conventions #7064)
• Analyzer + Code fix for requiring/prohibiting this/Me (Code Style: Analyzer + Code fix for requiring/prohibiting this/Me #7065)
• CodeStyle options should include control over "SimplifyToBase" (CodeStyle options should include control over "SimplifyToBase" #11821)
• CodeStyle: We should have a rule for whether to qualify static access with typename or not. (CodeStyle: We should have a rule for whether to qualify static access with typename or not. #14910)
• Analyzer + Code fix for modifiers (Code Style: Analyzer + Code fix for modifiers  #7066)
• Analyzer + Code fix for spacing (Code Style: Analyzer + Code fix for spacing #7067)
• IDE options to control the sorting of fields and properties (IDE options to control the sorting of fields and properties #4778)
• Code fixes for xml doc comments (Code Style: Code fixes for xml doc comments #7070)
• Code Style for usings (Code Style for usings #14450)
• Support running fixes automatically as part of code cleanup (Code Style: Support running Code Fixes automatically as part of a cleanup experience #7068)
• Duplicate code fixes reported if analyzer reference is installed as a VSIX as well as a nuget reference (Duplicate code fixes reported if analyzer reference is installed as a VSIX as well as a nuget reference #4030)
• Update existing code fixes and generation to obey newly added style options (Code Style: Update existing code fixes and generation to obey newly added style options #7069)
• Renaming a class in the VS editor should also rename the containing file (Renaming a class in the VS editor should also rename the containing file #5378)
• Enable one-click cleanup (Code Style: Enable one-click cleanup #8928)
• Introduce "suggestion" or "hint" classifications (Code Style: Introduce "suggestion" or "hint" classifications #9582)
• Support Sync File and Type Name in file/project/solution (Support Sync File and Type Name in file/project/solution  #14340)
• Fix all for "rename type" and "rename type" (Fix all for "rename type" and "rename type" #15921)
• Support refactoring to Sync Namespace and Folder Name (Support refactoring to Sync Namespace and Folder Name #14341)
• Improve cancellation of solution-wide refactorings (Improve cancellation of solution-wide refactorings #10097)
• Formatting: Add option to not perform any auto-formatting (Formatting: Add option to not perform any auto-formatting #8263)
• Add an option to apply code formatting to collection initializers (Add an option to apply code formatting to collection initializers #8269)
• Formatting: Support aligning multiple assignments based on their = (Formatting: recognize tab and multiple spaces as whitespace for custom alignment #16088)
• Discussion: Overriding with expression bodies (Discussion: Overriding with expression bodies #8380)
• Naming styles: No fix offered to remove '_' from names (Naming styles: No fix offered to remove '_' from names #10111)
• Reactivate the simplify-lambda code-fix. (Reactivate the simplify-lambda code-fix. #15295)
• Need 'fix-all' for naming style violations. (Need 'fix-all' for naming style violations. #14983)
• Visual Basic Auto-implement interface behaviour changed (Visual Basic Auto-implement interface behaviour changed #5898)
• Implement Interface: control generated property style (Implement Interface: control generated property style #13932)
• Feature request: Allow me to specify a desired max-column that code shoudl be wrapped against. (Feature request: Allow me to specify a desired max-column that code should be wrapped against. #15406)
• Fluent API formatting suggestion (Fluent API formatting suggestion  #15554)
• Allow a limit on method lengths (Code Style: Allow a limit on method lengths #8934)
• [Code Style] Implement a way to change style settings ([Code Style] Implement a way to change style settings  #13439)
• Code Style: Add fix to toggle between "using" and "using static" (Code Style: Add fix to toggle between "using" and "using static" #10274)
• Code Style: Support having a limit on the length of variable names (Code Style: Support having a limit on the length of variable names #10280)
• Code Style: Have the ability to share and enforce a common formatting scheme (Code Style: Have the ability to share and enforce a common formatting scheme #10285)

[sharwell]

I think the Roslyn (referring to this repository) should only be responsible for a subset of these, plus one you didn't mention:

• Ability to pass configuration options to analyzers (Code Style: Roslyn Workspace APIs need to support per-file options #7058, Code Style: OptionSet API available at compiler layer for analyzer authors to use #7059, Code Style: Options can be populated from .editorconfig files #7060, and/or Code Style: Coordinate with platform team about .editorconfig  #7061)
• Support running fixes automatically as part of code cleanup
• Ability for analyzers to define options that appear in pages under Tools → Options → Text Editor → C# → Formatting (and/or siblings of this)

This would allow the analyzers themselves to be implemented and distributed independently, and developed at a faster rate in a lighter-weight environment.

I believe that moving the analyzers themselves out of this repository and in general not giving them "special treatment" that doesn't apply to other analyzers will substantially benefit the entire analyzer ecosystem. And if you're already rewriting the formatter as a set of analyzers, I doubt you'll ever have a better time to do so. 😄

[Pilchie]

For your third bullet we had tentatively decided not to support it, and instead offer something more like VSCode's configuration experience - show a readonly view of our default .editorconfig file and allow you to override it per-user.

There are definitely tradeoffs to moving the rest of the work outside of the Roslyn repo - we'd like to bring this into the box as part of the default experience, and that's MUCH harder if we don't have everything packaged together. That isn't to say that we don't want to re-use a bunch of code, but we need to figure out the right approach to that.

Regarding rewriting the formatter as a bunch of analyzers, that's unlikely. Generally the formatting code is VERY performance sensitive, even when it has to make thousands of changes, and we're unlikely to be able to achieve that as a set of independent code fixes as opposed to the rewriter we have today. Additionally, we're not sure that the level of granularity StyleCop exposes around whitespace formatting (and distinct error codes, etc) are actually beneficial to anyone, so we were thinking of consolidating it into a simpler "Your code's whitespace is not consistent" sort of diagnostic, the fix for which would be to run the formatting engine.

[AdamSpeight2008]

Is there a way to bring the tab spacing options into this, that is to make them solution specific.
I personally like 2 space indentation, this project uses 4 space indentation.

[Pilchie]

@AdamSpeight2008 - yes, we'd want to solve that, likely as part of #7060.

[sharwell]

Additionally, we're not sure that the level of granularity StyleCop exposes around whitespace formatting (and distinct error codes, etc) are actually beneficial to anyone, so we were thinking of consolidating it into a simpler "Your code's whitespace is not consistent" sort of diagnostic, the fix for which would be to run the formatting engine.

Note that I wasn't saying StyleCopAnalyzers is necessarily the location for these, or that you should take the same rules. The takeaway from that experience with respect to this issue is the fact that we've been able to make rapid progress on the features while working in a small code base, and get these changes out to a reasonably large number of users without too much trouble. The analyzers mentioned in this issue are similar - they involve supporting a wide variety of strongly-held individual opinions. I believe they would benefit from the same type of development and distribution effort.

[alrz]

I'm not sure if this is relevant to this issue but it would be nice that code formatter preserve this style

using( ... ) try {
  ...
} catch {
 ...
}

[Pilchie]

@alrz That's not a style I've ever seen used before, and it's not something we have been tracking. Do you know of any codebases that actually use this style?

[alrz]

@Pilchie Probably it was Java, Java IDEs preserve this style. (I don't remember where I saw it though)

[mkrueger]

The roslyn formatter is very inflexible. However it's enough to support the allman code style and most K&R variants. So it is ok.

If you're really want to improve that and searching for ideas. I can recommend looking at Resharper or Jetbrains IDEA for a good set of formatting options. Or looking at the old NRefactory 5 option set:

https://github.com/icsharpcode/NRefactory/blob/master/ICSharpCode.NRefactory.CSharp/Formatter/CSharpFormattingOptions.cs

If it's worth implementing it - I don't know :)

+1 for making the options more fine grained & making the option API more usable.

[Pilchie]

Moving this to 2.0 (Preview) to continue working on it.

[alrz]

An option in "formatting" category to break method parameter list (or any other code if possible) to multiple lines (one per param) when it's longer than 80 chars would be great.

[lorcanmooney]

I see #3798 (Options can be populated from .editorconfig files), but will there be support for going the other way - exporting our current style preferences into an .editorconfig file?

[Pilchie]

We want to do that, but we're not sure we'll get there before RTM?

[jmarolf]

@Pilchie can we track this as a project instead of an issue?

[Pilchie]

I still haven't looked into "Projects", but it's on my todo list. agree that this isn't a great system.

[Pilchie]

Okay - I was going to triage and add more items to this list, and decided to just switch now. @kuhlenh Take a look at https://github.com/dotnet/roslyn/projects/4.