bkoelman / CSharpGuidelinesAnalyzer

Reports diagnostics for C# coding guidelines that are not already covered by Resharper.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

AV1561: Should exclude the `this` parameter of extension methods

BryceBarbara opened this issue · comments

Analyzer

AvoidSignatureWithManyParametersAnalyzer (1561)

Repro steps

public static class ExampleExtensions
{
    public static string DoSomething(this string instance, bool flag1, bool flag2, bool flag3)
    {
        return instance.ToString();
    }
}

Expected behavior

No warning, or a way to customize the behavior.

Actual behavior

ExampleExtensions.cs(3, 26): [AV1561] Method 'DoSomething' contains 4 parameters, which exceeds the maximum of 3 parameters

Hi @BryceBarbara, thanks for asking and providing repro steps.

Quote from AV1561:

To keep constructors, methods, delegates and local functions small and focused, do not use more than three parameters. (...) In general, the fewer the parameters, the easier it is to understand the method.

Based on that, it's unclear to me why the this parameter of an extension method should be excluded. While it is true that the this parameter is omitted when calling such a method, this rule is about the method declaration. The goal is to limit the number of parameters, to prevent cognitive overload for humans reading the method body. So it matters whether the this parameter is visible in the code or auto-generated by the compiler (which is the case on regular instance methods).

Why do you believe this should be excluded?

Note you can already configure a different limit for method parameters, see max_parameter_count and max_constructor_parameter_count at https://github.com/bkoelman/CSharpGuidelinesAnalyzer/blob/master/docs/Configuration.md.

Thank you for your quick reply and giving additional context for the rule.

Do you know if it's possible to have certain parameters excluded from the count? Like a cancellation token?

That's currently not possible. I suspect it's possible to add support for a list of fully-qualified type names in configuration, which would be ignored. Unfortunately my time is limited at the moment. Perhaps if more people ask for this I'll give it a try.