Add style option (and UI) for preferring file scoped namespaces

[CyrusNajmabadi]

UI looks like this:

and

This is exposed through the lightbulb as both an analyzer and a refactoring (similar ot how prefer-expression-body works). The analyzer will enforce the code style if set. The refactoring will allow you to switch to the either direction if you prefer. It looks like this:

Todo:

• Features taht generate code should respect this style and should generate a file-scoped-namespace if desired
• Tests

Relates to test plan: #49000

[Youssef1313]

I think both automation object and editorconfig UI need to be updated for this new option.

[Youssef1313]

I'm worried the severity variable here only reflects the option = value:severity syntax but not reflecting the dotnet_diagnostic.ID.severity = severity syntax.

[CyrusNajmabadi]

so this follows what we do with use-expression-body. i'm going to stick with this pattern under teh presumption that it's correct. if not, we shoudl fix it for all of these. i do not want to have multiple different patterns at the same time :)

[Youssef1313]

Tagging @mavasani to confirm if there is a problem here in which case I'll file an issue.

[Youssef1313]

Same comment here. Notification.Severity most likely doesn't reflect the dotnet_diagnostic..... syntax

[CyrusNajmabadi]

i reaklly do not want our features to deviate from each other. until there is a suitable new style we should keep our code consistent. Otherwise we'll just have a hodgepodge of impls with varying patterns that people have to udnerstand. If and when we have some new pattern that everything should follow, we can move all our code to that at once.

[davidwengier]

I haven't looked at the code yet, but is there a more descriptive name than "regular namespace"? Like "block-scoped namespace", or "block bodied namespace" to match how we talk about methods.

If new C# templates are going to use top level statements in .NET 6, I could see them using file-scoped namespaces in the same timeframe, or in the future, so that word "regular" will tend to lose its meaning.

[CyrusNajmabadi]

I haven't looked at the code yet, but is there a more descriptive name than "regular namespace"? Like "block-scoped namespace",

Yes, this is a good point. I will use 'block-bodied' or 'block-scoped' instead :)

[Youssef1313]

Note: #55043 (review) is not addressed yet

[CyrusNajmabadi]

@Youssef1313 I'm not doing editorconfig UI until #52343 is addressed. There are just too many duplicated strings in random places that have to be resolved before going that path.

[davidwengier]

[CyrusNajmabadi]

@jmarolf can you either add the EditorConfig side of this, or let me know when we can add EditorConfig settings without duplication? Thanks!

[AraHaan]

I second this so that way source generators (like CsWin32) can pick it up and then generate using file scoped namespace.

Bonus if something like this can be done to global usings as well too as well as a way to set what file it should place the global usings in (so source generators that generate code with usings could decide if it should add those usings or not add them and let the user manually add them to their global usings file).

[CyrusNajmabadi]

@AraHaan as mentioned already, a source generator can see these values when it executes and can generate accordingly.