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

Question

Premise

When using code analysis (or fxCop) with C# optional parameters you can get a warning of CA1026. The short reason¹ 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 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

Venable

Answer 1

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.

Roundfaced

"In terms of versioning": Phil Haack talks about that issue here. – Nummular

Version is the least of the problems with optional parameters - much worse is the maintainability issues they cause by undermining encapsulation. It's not possible to properly wrap optional-parameter-having methods, so people just don't (or do so badly by repeating the parameters and their defauls all over the place). I really don't think this warning should be disabled globally. Better to use structs/classes with fields that may or may not be set. – Dow

Interesting point @Eamon. I think they're so practical and when I write in java I roll my eyes ... but I also sigh when I overload a function and need to copy the defaults ... ! Now I'm all not sure what I think is best. Clearly microsoft have decided where they stand. – Clemence

Answer 2

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;
        }

Riotous

Answer 3

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

Fidellia