Are optional parameters really an advisable thing to use ?

[pamelafluente]

Hi guys,

In the past I have used several time optional parameters in my
function.

But Now I am more inclined to think that they are more dangerous than
useful, and probably better to be avoided.

I'd like to hear your various opinions on this matter.

Thanks,

-P

[Robinson]

<pa***********@ libero.itwrote in message
news:11******** **************@ b28g2000cwb.goo glegroups.com.. .

>
Hi guys,

In the past I have used several time optional parameters in my
function.

But Now I am more inclined to think that they are more dangerous than
useful, and probably better to be avoided.

I'd like to hear your various opinions on this matter.

Thanks,

-P

Personally I've never used them. I usually implement methods with varying
numbers of parameters (one for each), that call into a "generalize d" method
that takes all of the parameters, using suitable defaults. I find this is
easier to extend. It's more code to write, but less potential for
hazards/confusion I think Still, they are particularly useful when dealing
with Office Interop and COM I have to say.

Public Sub Foo ( ByVal Variable As Integer )

Foo ( Variable, -1, -1 )

End Sub

Public Sub Foo ( ByVal Variable1 As Integer, ByVal Variable2 As Integer )

Foo ( Variable1, Variable2, -1 )

End Sub

Public Sub Foo ( ByVal Variable1 As Integer, ByVal Variable2 As Integer,
ByVal Variable3 As Integer )

.......

End Sub

[Herfried K. Wagner [MVP]]

<pa***********@ libero.itschrie b:

In the past I have used several time optional parameters in my
function.

But Now I am more inclined to think that they are more dangerous than
useful, and probably better to be avoided.

I wonder how you come to the perception that optional parameters are
dangerous.

Personally I use optional parameters whereever it makes sense. On the other
hand I use overloading when it makes more sense than optional parameters.
Optional parameters' default values must not be changed once a library has
been published (well, method signatures must not be changed too), they can
be seen as part of the interface.

Thus optional parameters should only be used if the optional parameter's
default value won't change in future and if the default value is not an
implementation detail. If the latter is the case, using overloads is the
better solution. If the first is the case, use a normal parameter, for
example.

Note that C# does not support optional parameters. Methods having optional
parameters can be defined in C# but they cannot be consumed the way this is
done in VB. Always all parameters must be specified in the method calls.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[AMercer]

In the past I have used several time optional parameters in my

function.
But Now I am more inclined to think that they are more dangerous than
useful, and probably better to be avoided.
I'd like to hear your various opinions on this matter.

1. Fxcop says to avoid them with the rule "Default parameters should not be
used." Optional parameters, it is said, can lead to interoperabilit y
problems even within .net (VB supports optional parameters and C# does not).
The preferred alternative is overloading. So, what is this about? Does VB
overreach or is C# deficient? Is this a problem in .net implementation or do
optional parameters pose theoretically unsolvable problems? Interesting
questions in general, but not relevant to me, because I use VB only. In the
VB only world, I don't think optional parameters pose any known technical
problems.

2. As to the question of "more dangerous than useful", ie the utility of
optional parameters.... Well, I like them, and I use them often. I also use
overloads. I estimate that my code uses optional parameters versus overloads
in proportions of about 80-20. As you would expect, I use optional
parameters when the calling sequences are very similar, and I use overloads
when the calling sequences are very different. I even have a case of two
overloads, and each has optional parameters. I usually code a default value
of an optional parameter is Nothing (or for value types, "", 0, or similar)
which indicates something like 'not applicable' or 'do nothing'. In these
newsgroups, I recently read an example where an optional parameter was
SalesTax and the default value was 6 (indicating 6%) - I never use optional
parameters in this way. I do have some cases of a nonzero numerical optional
parameters, for example a string length parameter defaulted to the worst
case, or a multiplicative scaling factor defaulted to one (meaning multiply
by one, hence no scaling), but these nonzero parameters are quite different
from the sales tax example. I also have a few classes that implement one
constructor having all parameters optional - I have found this to be
convenient but not necessary. In short, I am in favor of judicious use of
optional parameters.

[Herfried K. Wagner [MVP]]

"AMercer" <AM*****@discus sions.microsoft .comschrieb:

> In the past I have used several time optional parameters in my
function.
But Now I am more inclined to think that they are more dangerous than
useful, and probably better to be avoided.
I'd like to hear your various opinions on this matter.

1. Fxcop says to avoid them with the rule "Default parameters should not
be
used." Optional parameters, it is said, can lead to interoperabilit y
problems even within .net (VB supports optional parameters and C# does
not).
The preferred alternative is overloading.

The problem with overloading is that it cannot always be used to archieve
the same behavior possible with optional parameters and that overloading has
different characteristics . Overloading hides the value of the parameter
passed to the method, optional parameters don't. If the value is actually
an implementation detail, overloading is the way to go, otherwise using
overloading is nonsense.

Additionally I wonder if FxCop also barked on C# code which contained
operator overloading before VS 2005 came out. There are no valid arguments
against supporting optional parameters but for some reason the C# team
refuses to support them although it would strengthen the link between C# and
..NET.

In these newsgroups, I recently read an example where an optional
parameter was
SalesTax and the default value was 6 (indicating 6%) - I never use
optional
parameters in this way.

That's a really bad sample because of the function is exposed by a library
functionaliy will break if the default percentage changes. Taxes are very
likely to change over time. Better solution:

\\\
Public Class Bla
Public ReadOnly DefaultSalesTax As Double = 6

Public Sub Foo(ByVal SalesTax As Double)
...
End Sub

' Performs 'Foo' operation using the default sales tax.
Public Sub Foo()
Foo(Me.DefaultS alesTax)
End Sub
End Class
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[jeff]

in response to the 6% sales tax ... default optional parameter ... wow...

everybody has their reasons for using optional parameters ... or function
overloading.

I can not agree or disagree with either ... use what you like and what you
are comfortable with ...

I like to use overloading ... for the following reasons...

- many functions have 'regional' / 'divisional' / 'office' defaults ... that
are stored in the database - sales tax being one ;-)
- One function name can have many different parameter lists and parameter
sequences depending on where it is being called from ... I find overloading
gives me the flexibility to easily identify when a parameter is not
included, and lookup its value in the database ... and have the default
value reflect the current user's selected office, division, region and so on
.... and allow the user to easily switch between offices without having to
reset a whole bunch of global / default values...

- i think people are misguided by the statement ... more dangerous than
useful ... come from the following situation .. I have encountered it before
.... u write a function ... another programmer uses it, who does not
understand optional parameters ... thinks he needs to fill in all the
parameters with what he thinks are the default values ... problem ... done.
Also, the dangerous could be encountered when you have 5 optional parameters
and you want to populate the fifth one ... but forget to include the right
number of comma's and parameter 5 is actually passed into parameter 4 - same
datatype.

Again...it is your choice ... and both ways are right and both ways are
wrong - it is personal choice.

Jeff.

PS: VB.Net support for optional parameters ... is this due to the fact that
traditional VB did not support 'overloading' and many VB programs used
'optional parameters' in an attempt to support OOP principles? So, is VB
deficient and C# overreach?



"AMercer" <AM*****@discus sions.microsoft .comwrote in message
news:29******** *************** ***********@mic rosoft.com...

> In the past I have used several time optional parameters in my
function.
But Now I am more inclined to think that they are more dangerous than
useful, and probably better to be avoided.
I'd like to hear your various opinions on this matter.

1. Fxcop says to avoid them with the rule "Default parameters should not
be
used." Optional parameters, it is said, can lead to interoperabilit y
problems even within .net (VB supports optional parameters and C# does
not).
The preferred alternative is overloading. So, what is this about? Does
VB
overreach or is C# deficient? Is this a problem in .net implementation or
do
optional parameters pose theoretically unsolvable problems? Interesting
questions in general, but not relevant to me, because I use VB only. In
the
VB only world, I don't think optional parameters pose any known technical
problems.

2. As to the question of "more dangerous than useful", ie the utility of
optional parameters.... Well, I like them, and I use them often. I also
use
overloads. I estimate that my code uses optional parameters versus
overloads
in proportions of about 80-20. As you would expect, I use optional
parameters when the calling sequences are very similar, and I use
overloads
when the calling sequences are very different. I even have a case of two
overloads, and each has optional parameters. I usually code a default
value
of an optional parameter is Nothing (or for value types, "", 0, or
similar)
which indicates something like 'not applicable' or 'do nothing'. In these
newsgroups, I recently read an example where an optional parameter was
SalesTax and the default value was 6 (indicating 6%) - I never use
optional
parameters in this way. I do have some cases of a nonzero numerical
optional
parameters, for example a string length parameter defaulted to the worst
case, or a multiplicative scaling factor defaulted to one (meaning
multiply
by one, hence no scaling), but these nonzero parameters are quite
different
from the sales tax example. I also have a few classes that implement one
constructor having all parameters optional - I have found this to be
convenient but not necessary. In short, I am in favor of judicious use of
optional parameters.

[rowe_newsgroups]

Also (correct me if I'm wrong) VB is the only .Net language that
supports optional parameters, the other languages use overloading. Like
Robinson said, Overloading methods provides the same functionality as
optional params but is safer, easier to maintain, and is compatible
with the other .Net languages.

I usually implement methods with varying numbers of parameters (one for each), that call into a "generalize d" method that takes all of the parameters, using suitable defaults.

Why not just overload the "generalize d" method? - Just curious

Thanks,

Seth Rowe

Robinson wrote:

<pa***********@ libero.itwrote in message
news:11******** **************@ b28g2000cwb.goo glegroups.com.. .

Hi guys,

In the past I have used several time optional parameters in my
function.

But Now I am more inclined to think that they are more dangerous than
useful, and probably better to be avoided.

I'd like to hear your various opinions on this matter.

Thanks,

-P

Personally I've never used them. I usually implement methods with varying
numbers of parameters (one for each), that call into a "generalize d" method
that takes all of the parameters, using suitable defaults. I find this is
easier to extend. It's more code to write, but less potential for
hazards/confusion I think Still, they are particularly useful when dealing
with Office Interop and COM I have to say.

Public Sub Foo ( ByVal Variable As Integer )

Foo ( Variable, -1, -1 )

End Sub

Public Sub Foo ( ByVal Variable1 As Integer, ByVal Variable2 As Integer )

Foo ( Variable1, Variable2, -1 )

End Sub

Public Sub Foo ( ByVal Variable1 As Integer, ByVal Variable2 As Integer,
ByVal Variable3 As Integer )

.......

End Sub

[David Anton]

IronPython (the newest .NET language) allows optional parameters.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: VB to Python converter
"rowe_newsgroup s" wrote:

Also (correct me if I'm wrong) VB is the only .Net language that
supports optional parameters, the other languages use overloading. Like
Robinson said, Overloading methods provides the same functionality as
optional params but is safer, easier to maintain, and is compatible
with the other .Net languages.

I usually implement methods with varying numbers of parameters (one for each), that call into a "generalize d" method that takes all of the parameters, using suitable defaults.

Why not just overload the "generalize d" method? - Just curious

Thanks,

Seth Rowe

Robinson wrote:

<pa***********@ libero.itwrote in message
news:11******** **************@ b28g2000cwb.goo glegroups.com.. .

>
Hi guys,
>
In the past I have used several time optional parameters in my
function.
>
But Now I am more inclined to think that they are more dangerous than
useful, and probably better to be avoided.
>
I'd like to hear your various opinions on this matter.
>
Thanks,
>
-P
>

Personally I've never used them. I usually implement methods with varying
numbers of parameters (one for each), that call into a "generalize d" method
that takes all of the parameters, using suitable defaults. I find this is
easier to extend. It's more code to write, but less potential for
hazards/confusion I think Still, they are particularly useful when dealing
with Office Interop and COM I have to say.

Public Sub Foo ( ByVal Variable As Integer )

Foo ( Variable, -1, -1 )

End Sub

Public Sub Foo ( ByVal Variable1 As Integer, ByVal Variable2 As Integer )

Foo ( Variable1, Variable2, -1 )

End Sub

Public Sub Foo ( ByVal Variable1 As Integer, ByVal Variable2 As Integer,
ByVal Variable3 As Integer )

.......

End Sub

[Robinson]

Why not just overload the "generalize d" method? - Just curious

Yes, that is what I'm doing. Overloading provides variations in
functionality, which you could equate with variations in "default"
parameters in this instance. Really I suppose a lot depends on how many
parameters your method has. If it has lots then overloading for each
variation is going to be more difficult to maintain and a lot more code.
Once again, it doesn't pay to be religious about it, just pick and mix ;).

[Tom Shelton]

pa***********@l ibero.it wrote:

Hi guys,

In the past I have used several time optional parameters in my
function.

But Now I am more inclined to think that they are more dangerous than
useful, and probably better to be avoided.

I'd like to hear your various opinions on this matter.

Thanks,

-P

Since were talking opinions, I guess I'll give my 2 pennies worth...

I would not classify optional parameters as dangerous, though I believe
they should be avoided when used in publicly exposed interfaces.
Mainly, because as Herfried indicated, their default values become part
of the interface. This can lead to maintainence issues if a default
value changes after the class is published. Further, it can lead to
interoperabilit y problems if you plan to use the code from other .NET
languages (even if you don't plan on it now, I think it is always a
good idea to take this into consideration anyway).

So, my rule is basically - if it is part of a publicly exposed
interface, use overloading exclusively. If the class is part of the
internal implementation, then I don't really think it makes much
difference - though, I would tend to overloading simply for
consistancy.

--
Tom Shelton