开发者

CA1026 (all parameters should have default values) and extension methods

开发者 https://www.devze.com 2023-01-08 15:11 出处:网络
Premise When using code analysis (or fxCop) with C# optional parameters you can get a warning of CA1026. The short reason1 for this is not suppling all parameters with a default value.

Premise

When using code analysis (or fxCop) with C# optional parameters you can get a warning of CA1026. The short reason1 for this is not suppling all parameters with a default value.

The declaration below rightly generates this warning

public Color GetColor(bool red, bool blue = true, bool green = true)

However there is a situation where you could not supply all parameters with a default, and that is extension methods. So the declaration below generates the warning because of the first parameter:

public static bool ValidateRules(this string s, Rules rules = Rules.Default)

The compiler will not let you specify a default value on the this parameter so the only two solutions is to:

  1. Ignore the warning, which I do not like doing because it leads to bad practices.
  2. Not use extension methods, which I do 开发者_JAVA技巧not like doing because I find extension methods make the code more readible.

Questions

  • Are the above two options the only way to solve this?
  • Is fxCop/Code Analysis incorrect in it's check?

  1. The long reason


It's not warning you for not having defaults for all parameters - it's warning you for using optional parameters at all.

Personally I would disable this particular warning. When used with care, I think optional parameters are fine. You should think carefully about them particularly in terms of versioning of the default parameter value and in terms of languages which don't support them (including C# before v4) but in many environments the downsides really aren't an issue - and you can end up with much simpler code than by specifying overloads all over the place.


An argument that I am missing in Jon Skeet's answer is also about maintainability: Default values are always filled in with it's value in the IL (intermediate language). This is an issue if you're using external libraries.

Here are steps to reproduce a simple example:

  1. Create a console app
  2. Add a ClassLibrary project to it
  3. Add the following code:

Program.cs

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            var obj = new Class1();

            Console.WriteLine(obj.Foo());
            Console.ReadKey();
        }
    }
}

and in your Class1.cs

namespace ClassLibrary1
{
    public class Class1
    {
        public string Foo(string str = "http")
        {
            return str;
        }
    }
}

If you run it you will see 'http', as expected.

  1. Now change "http" to "https"
  2. Compile only the library (maybe even unload the console project)
  3. Copy the dll from the library's bin folder to the console app's bin folder by hand
  4. Run the console app from the command line, not from within VS!

You will still see http! With ILSpy you can see that http is hardcoded in the console app.

In this case this could lead to a security issue if the developer thinks he is safe by replacing the "http" to "https" in the default value.

So if external libraries are updated always compile your code again. Or just don't use default values.

Just create a separate method:

        public string Foo()
        {
            return Foo("https");
        }

        public string Foo(string str)
        {
            return str;
        }


You can suppress the warning on a case-by-case basis.

0

精彩评论

暂无评论...
验证码 换一张
取 消