This question already has an answer here:
Since C# added optional parameters is it considered a better practice to use optional parameters or method overloads or is there a particular case where you would want to use one over the other. i.e a function w/ lots of parameters would be better suited w/ optional parameters?
Optional parameters are meant to facilitate COM object interactions as COM objects use lots of optional parameters. So if you're doing P/Invoke or COM object stuff, prefer optional parameters. Otherwise, method overloading is the proper way to go as it saves a lot of confusion.
Optional parameters require a default value (I only assume), and thus in some cases it might be difficult to supply one. Why? Well some classes need runtime information to get initialized which may not be available to the compiler.
When it comes to primitive types, the answer may have to do with if a default value can be assumed, or if the absence of a parameter might signify different behavior by the method.
Rather than overloading or named optional parameters, I've grown to like object initializers very much. All you need in the class is a parameterless constructor, and public properties for anything you want to set on initialization.
Assuming class Bar has public string properties "Name" and "Pet", you can construct a new object like this.
The advantage is that you don't need a separate overload for each combination of values that you want to initialize.
I'm not sure there's a canonical answer for this - it's subjective and case-by-case. However, in my opinion optional parameters create more explicit APIs and therefore, I generally prefer them over method overloads.
Specifically, when working with Intellisense I much prefer to see this:
Over this:
Where I may have to guess (or look up documentation) for what the value of param1 and param2 will be if I don't specify.
Code Analysis in Visual Studio and FxCop recommends you do not use optional arguments in public APIs (rule CA1026: Default parameters should not be used). The reason given is that not all .NET languages support them.
I think a better reason to avoid them though, is that they can introduce either runtime or compile-time problems if you add more overloads in a version 2.0 of your API. Phil Haack explains here.
I'm going to adopt Phil's conclusion: Optional parameters were designed to support COM interop; if you're not using COM, leave them alone.
Optional parameters are nice, but should be used when it makes sense. Optional parameters often muddy the intent of the method -- If there is another alternative I would lean towards the alternative.
Part of the need for optional parameters and named parameters is because COM allowed optional and name parameters:
MSDN
SomeNewKid from forums.asp.net puts succinctly:
http://forums.asp.net/t/386604.aspx/1
Keep in mind that optional parameters are a syntactical sugar:
Reflector C#:
IL: