Are optional parameters really an advisable thing to use ?

  • Thread starter Thread starter pamelafluente
  • Start date Start date
P

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
 
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
Click to expand...

Personally I've never used them. I usually implement methods with varying
numbers of parameters (one for each), that call into a "generalized" 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
 
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.
Click to expand...

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.
 
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.
Click to expand...

1. Fxcop says to avoid them with the rule "Default parameters should not be
used." Optional parameters, it is said, can lead to interoperability
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.
 
AMercer said:
1. Fxcop says to avoid them with the rule "Default parameters should not
be
used." Optional parameters, it is said, can lead to interoperability
problems even within .net (VB supports optional parameters and C# does
not).
The preferred alternative is overloading.
Click to expand...

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.
Click to expand...

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.DefaultSalesTax)
End Sub
End Class
///
 
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?
 
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 "generalized" method that takes all of the parameters, using suitable defaults.
Click to expand...

Why not just overload the "generalized" method? - Just curious

Thanks,

Seth Rowe
 
Why not just overload the "generalized" method? - Just curious
Click to expand...

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 ;).
 
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
Click to expand...

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
interoperability 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.
 
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
Click to expand...

Wierd... The opinion I wrote earlier, never has arrived. Anyway, here
is my take on this in a nutshell:

Q: Are optional parameters dangerous?
A: I would not classify them as dangerous, but I do believe a little
knowledge and foresight should be involved in the decision to use
optional parameters. As Herfried said, the default values for optional
parameters become part of the classes interface - part of it's contract
if you will. This can lead to maintainence issues if you decide to
change that default value after the interface has been published.
Further, optional parameters are not supported by most .NET languages.
You may not care, because you think your code will only be used from
VB.NET - but, that is short sighted IMHO. You never know when
requirements may change.

So - given the above here is my personal rule... Don't use optional
parameters in any public interface. They are fine for internal
implementations, but even then I favor overloading simply for
consistancy.
 
I use them except when my interfaces need to be CLR compliant. If the
interface will be a VB interface only, go right ahead, especially when
you're simply adding additional parameters to the base required parameters:

foo(string)
foo(string, bool)
foo(string, bool, integer)

can be coded as

foo(string, optional bool, optional integer)

However, if the interface is

foo(string)
foo(integer, bool)

etc., I think overloading is easier to understand since the parameters are
different early on.

As you can see from the variety of responses, this question is somewhat a
matter of style and taste. Just be consistent in your code.

Mike Ober.
 
Back
Top