search

DotNetAnalyzers / AsyncUsageAnalyzers

Now superseded by Microsoft/vs-threading
https://github.com/Microsoft/vs-threading
Other
121 stars 18 forks source link

UseConfigureAwait rule inappropriate in many contexts #24

Closed AArnott closed 9 years ago

AArnott commented 9 years ago

The default behavior of await is appropriate for app development. In some libraries, it may be appropriate to add .ConfigureAwait(false) at the end of an awaitable expression, but there are plenty of contexts where the default behavior is appropriate.

Yes, I know rules can be disabled. But perhaps the default should be to disable the rule and let users enable it when they know they're working on a shared library project for which no requirement to abide by the SynchronizationContext rules.

sharwell commented 9 years ago

The rule is enabled by default, but uses DiagnosticSeverity.Hidden. This combination allows the analyzer to offer the lightbulb on lines where ConfigureAwait is not used, but will not produce any other messages related to this diagnostic. In this mode, it is effectively an on-demand refactoring operation.

Compared to the current behavior, disabling the rule by default would only have the effect that you could no longer use the lightbulb to insert a ConfigureAwait(false) call.

AArnott commented 9 years ago

That seems like a good approach. StyleCop.Analyzers.Tests evidently has the rule turned on so I assumed that it was the default setting.