C# Optional Parameters vs. Method Overloading

I was recently working on some data access/repository code and came across a nice generic repository implemetation for working with EntityFrameworks DataContexts. But when I ran our build through SonarQube, it got itself quite bent out of shape about the following recommendation.

Use the overloading mechanism instead of the optional parameters.

Hmm... Why doesn't SonarQube like optional parameters. They've been a feature of C# since v4.0 and are extremely useful. Consider the following interface.
In the first version, there's a single method definition that allows the consumer pick and choose what variety of parameters to pass.

In the second verion, you need 8 different method overloads to achieve the same.

So why is SonarQube recommending that latter over the former. Well there's a few reasons that may not be obvious. These methods are going to be public facing. They are the surface of your API and will be exposed to the world outside your DLL. In my case, my C# Service's were calling the repository in a different DLL. But not all consumers support Optional Parameters. Java and C++ do not have an equivalent concept available to them. Another reason is that these defaults do not "live" in your DLL per say, but get baked into the call site of the DLL that references them at compile time. So a change in the default values requires the caller application to be recompiled and redeployed rather than just an update of your API library.

Hence why the .NET Frameworks BCL libs all favour Method Overloading over Optional Parameters. But in my case this is internal project code, part of an application stack that gets deployed as a whole.

There's a benefit to brevity in my code and I'd prefer the implementation to be more concise since I having full control of both the API and Caller as well as the deployment process. So Optional Parameters it is.

If on the other hand you're writing public API libs for publishing to nuget or you operate in an environment where partial deployments of libraries and components occur, go with Method Overloading.

~Eoin Campbell