Are optional parameters really an advisable thing to use ?

28 Sep 2006 10:58 AM

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

28 Sep 2006 11:18 AM

Robinson

<pamelaflue***@libero.it> wrote in message
Show quoteHide quote

news:1159441101.084222.109000@b28g2000cwb.googlegroups.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 "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

28 Sep 2006 3:02 PM

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 "generalized" method that takes all of the parameters, using suitable defaults.

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

Thanks,

Seth Rowe

Robinson wrote:
Show quoteHide quote

> <pamelaflue***@libero.it> wrote in message
> news:1159441101.084222.109000@b28g2000cwb.googlegroups.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 "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

28 Sep 2006 4:03 PM

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

Show quoteHide quote

"rowe_newsgroups" 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 "generalized" method that takes all of the parameters, using suitable defaults.
>
> Why not just overload the "generalized" method? - Just curious
>
> Thanks,
>
> Seth Rowe
>
> Robinson wrote:
> > <pamelaflue***@libero.it> wrote in message
> > news:1159441101.084222.109000@b28g2000cwb.googlegroups.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 "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
>
>

28 Sep 2006 4:24 PM

Robinson

> Why not just overload the "generalized" 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 ;).

28 Sep 2006 11:45 AM

Herfried K. Wagner [MVP]

<pamelaflue***@libero.it> schrieb:

> 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/>

28 Sep 2006 12:53 PM

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 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.

28 Sep 2006 1:43 PM

Herfried K. Wagner [MVP]

"AMercer" <AMer***@discussions.microsoft.com> schrieb:
>> 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 interoperability
> 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.DefaultSalesTax)
    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/>

28 Sep 2006 2:04 PM

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?

Show quoteHide quote

"AMercer" <AMer***@discussions.microsoft.com> wrote in message
news:294F2B7F-762E-4C23-8FB7-A52C45C25AB0@microsoft.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 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.
>

28 Sep 2006 5:28 PM

Tom Shelton

pamelaflue***@libero.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
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.

--
Tom Shelton

28 Sep 2006 10:12 PM

Tom Shelton

pamelaflue***@libero.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

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.

--
Tom Shelton

29 Sep 2006 2:55 AM

Michael D. Ober

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.

<pamelaflue***@libero.it> wrote in message
Show quoteHide quote

news:1159441101.084222.109000@b28g2000cwb.googlegroups.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
>
>

2 Oct 2006 1:56 PM

pamelafluente

Thanks all for all your valuable opinions.

-P