[2005] Optional Arguments vs. Overloading

[bgmacaw]

I wanted to get some opinions of this question that came up today: Which is best to use and when, Optional arguments or Overloading?

Let's take this example where a source file is copied to multiple locations:

Private Function TransferFile(ByVal sourceFileName As String, _
                       ByVal targetFileNames As List(Of String), _
                       ByVal createTargetFolders As Boolean, _
                       ByVal overwriteTargetFiles As Boolean, _
                       ByVal deleteSourceFile As Boolean) As Boolean

If you wanted to make the 3 boolean arguments optional would you simply change the definition for the to Optional and add the default value? Or would you create separate overloads for each?

My vote here would be for Optional since you can't really create an overload for each case and the code behind the operation is basically the same for each situation.

Where I see overloads as useful would be if you had significantly different operations for each parameter type, for example:

Private Function GetHeader(ByVal fileName As String) As String
 
Private Function GetHeader(ByVal clientID As Guid) As String

The first overload uses the file name string while the second uses a database lookup to find the stored file header information based on the provided Guid. This is a case where you should use overloading since two very different operations are called for although the desired result, a header string, is the same.

Any other thoughts/opinions/comments on this?

[bmahler]

I personally would use an overload if the code being executed would be drastically different if the other parameter is present. Otherwise I would just use an optional parameter if it is going to execute pretty much the same code with a slight modification due to the optional parameter.

[FourBlades]

With as many options as you have there I'd use Overloading so that the user is less confused.
They can choose which they want to use.

Let them choose the exact combination they want.

[SharkC382]

I think since the strings are probably never optionable (I could be wrong), but the booleans are, then Overloading might be Overkill. The booleans can have default values for the most common uses, so I'd vote for Optional.

Matt

[FourBlades]

It might just be best to try the role of the programmer who has to use it and see which way works best.
If you are the only person who's going to use it then do whichever is easiest for you.

[wossname]

They are essentially the same thing but implemented in different ways.

For instance, C# does not allow optional parameters (and rightly so), however you can get precisely the same effect with overloading.

You should use overloading.

[timeshifter]

I'm of the opinion of "use the right tool for the job." I have a couple of places where overloading would be a waste, since the function does basically the same thing either way, just passing different values from the optionals. Why bother creating a whole new sub to overload when it's not needed?

[techgnome]

I always overload.... then in the subs/functions that have the fewer parameters, call the overload of the next highest order, passing in values as the defaults for the ones that weren't previously passed in..... I think that makes sense....

-tg

[jmcilhinney]

Note that the only place in VB you'll find optional parameters are in Runtime functions carried over from VB6. All the methods in the My namespace that have variable argument lists are overloaded. Microsoft obviously consider overloading to be preferable. I would also suggest using overloading for clarity and consistency. If you use optional parameters and the method gets called from C# code then all parameters would have to be specified because, as wossname said, C# doesn't support optional parameters. Use overloading all the time and there's never any need to ask this question. You'll never have to write more than a few extra lines of code so to use optional parameters to save yourself writing more code is not a valid argument.

[FourBlades]

Not only that but I'd rather use a class that someone else wrote that says "you can you this; or this; or finally this" -- choose which one (Overloading).
It's more confusing from my point of view to see "well you can use this and maybe this and maybe that" (Optional Parameters). I then have to do more brain work.
Not that I don't want to work; it's just that, to me, one of the purposes of a well tested class is that it's supposed to be easy to use; as opposed to writing the code from scratch.
.NET was built on the premise of re-using and extending classes -- either someone else's or your own. So I appreciate a class who's functions are easy to understand.

[bgmacaw]

If you use optional parameters and the method gets called from C# code then all parameters would have to be specified because, as wossname said, C# doesn't support optional parameters.

Well, I don't consider "just because C# does it that way" to be a valid argument when you're developing in-house components and applications in an organization that only uses VB. The way C++ programmers and, I'd guess by extension C# programmers, often code boolean optional parameters is through a bitmask. Are they told not to use this because bitwise operations are a little different in VB? I think some VB.NET programmers are far too consumed with trying to emulate C# but that's a another topic.

But, back to the point, my concern over using overloading on more trivial routines or very similar routines is that the more code you add, particularly code that might be redundant/cut-n-pasted, increases the chance for the introduction of bugs and makes the maintainability of the module more troublesome. The way I've approached this to have the overloads with fewer parameters call the one with the most parameters using their defaults. That way the meaningful code is all in one place. For more complex overloads, I have private routines that hold common code.

[jmcilhinney]

Well, I don't consider "just because C# does it that way" to be a valid argument when you're developing in-house components and applications in an organization that only uses VB.

I didn't say, or even imply, that you should do it that way "just" because C# does. That's only one factor of several.

[bgmacaw]

I didn't say, or even imply, that you should do it that way "just" because C# does. That's only one factor of several.

I was combining your comment with Wossname's because they did seem to support the C# way over the VB way. The suggestion that I should code to accommodate C++/C# in my in-house programs bothers me because C++/C# programmers rarely show the same deference to VB.

But, to get back to the point, do you think it is a proper overloading strategy when you have several very similar routines to only fully code the most expansive one and have stubs that call this routine for the other, simpler ones? Or do you think each routine should be individually coded? Or should they all be stubs that call a central, private, method?

[techgnome]

I was combining your comment with Wossname's because they did seem to support the C# way over the VB way. The suggestion that I should code to accommodate C++/C# in my in-house programs bothers me because C++/C# programmers rarely show the same deference to VB.

So be the bigger developer.

But, to get back to the point, do you think it is a proper overloading strategy when you have several very similar routines to only fully code the most expansive one and have stubs that call this routine for the other, simpler ones? Or do you think each routine should be individually coded? Or should they all be stubs that call a central, private, method?

I've done it both ways..... it depends on what it does. If it's complex enough, and I have more than two overloads, I'll go with the central function. But if there are only two, I'll code it in the larger one, then have the simpler one call the larger one, passing in default values for the missing parameters.

=-tg