Is use of default parameters/optional arguments a bad practice in C#? (Q263)

I wonder if people (including myself) would feel as dirty if this would have been a feature of C# from the beginning. I tend to think not. I'd say use them if you can. But watch out for too may parameters on your method. But that goes for traditional overloads as well. 

That is a very good point! And its very easy to clutter up the parameters, and what should have been a class with a semi-busy constructor becomes a super-method instead. 

The problem boils down to the fact that default parameters are baked into callers instead of callees. This means that future maintenance of the code can change the default value on one assembly and all of sudden you have unexpected behavior in your application. 

I have a (rather strong)  C++ background, so default parameters are very common to me. However, given the dynamism in managed languages, the reuse of libraries and partial updates of LOB applications, I'm now very afraid of default parameters. I use them on internal classes only, or, on peculiar cases, in public classes for reference types (which can only be assigned null). 

I just wish MSFT implemented it differently, baking the value into the method metadata or even doing some hard lifting and creating multiple methods. 

This should be mentioned in the post. Because this is what is wrong and that's why I don't ever use default parameters. C# creators ommited implementing default parameters because they thought they were bad. Now they included it. I don't like it. 

If I add a new optional parameter to a method, it is my responsibility that the default value implement the previous behavior, therefore there is no unexpected behavior.

Plus previous unit tests should catch any breaking changes. 

it is mentioned in the post but I will make sure it is more clearly, I've done a poor job there so thank you for pointing that out. I also only use them (if I do) on internal classes, but usually end up breaking my code up as the method seems to grow in size and functionality. I do wish I knew C++ because it would be very interesting to compare. Let me know if any of you write about that, I would love to link that here. 

Another one to watch out for is constructors. For example:

public class SomeClass
{
    public SomeClass(bool something = true)
    {
    }
}

Although I can instantiate this with new SomeClass() it doesn't have a public parameterless constructor. Which means this will fail:

private static void DoSomething()
    where T : new()
{
}

DoSomething();

Similarly doing Activator.CreateInstance() will fail; this caught me out recently. 

I find optional/default parameters to be absolutely awesome used well.

In general i always have class similar to 

public class Foo {
public Foo() : this(null,null){}
public Foo(IEnumerable ints = null, IEnumerable bars = null)
{
if(ints != null) _ints = new List(ints);
if(bars != null) _bars = new List(bars);
}

To handle initialization.

With methods, i always attempt to create as few overloads as possible by sane usages of optional parameters. 


Also something wierd about the comment form prevents me from entering my name or email in firefox, i had to switch to chrome. 

Total nay on optional arguments. They're nice bandaids to allow you to extend as functionality expands and exposes flaws in your architecture, but that's what they should be treated as: markers of flaws in your architecture.  

Default/Optional parameters = code smell. 

I think it's a good question. I never thought about it. As a Clean Code lover, I tend to think that optional parameters are a feature to avoid. Defaults sometimes are not clear. Making things explicit as normally a good ideal. 

However, it can be useful for a few situations like short utility methods that do common tasks widely understood, without hiding the meaning or causing ambiguity. 

Many people don't like using optional parameters in VB.net and it has always had optional parameters so I don't think it would make any difference if C# had optional parameters from the beginning. 

I say no thanks to optional parameters.
An optional parameter indicates two or more decision paths.
IMO this will violate one's desire to write single responsibility methods.

The only use case I've ever seen for optional parameters are when trying to retrofit legacy code.

Also, consider the .net framework. Do you see lots of overloaded methods in the api's or optional methods?
I strongly recommend checking out the Framework Design Guidelines book that was written from the .net guys.