While I don't see that there would be an actual "right" answer to this, I'm
sure experienced programmers can say what tends to work and what doesn't.
I have a situation where I will be passing one object to another so it can
be configured and used internally. I could pass it with a number of
parameters, probably 5 or 6, or I could pass it with only a few parameters
and have all the rest specified with different method calls.
Does it tend to be easier, in the long run, to have one call with a lot of
parameters (which can be hard to keep track of without an IDE prompting
you) or does it tend to work better to keep the parameter list short and
use several calls? My thought is that the former wold probably work
better, especially if I use the class I'm writing months later, after
having forgotten the internals, since it's easier to keep the parameters
straight than to remember that several calls have to be made to set
everything up.
I'm wondering if more experienced programmers have any experience or
comments that indicates whether a long list of parameters or a number of
different method calls tend to work better.
Thanks!
Hal
Patricia Shanahan - 15 Jun 2007 03:50 GMT
> While I don't see that there would be an actual "right" answer to this, I'm
> sure experienced programmers can say what tends to work and what doesn't.
[quoted text clipped - 20 lines]
>
> Hal
One consideration is whether the parameters have usable defaults.
I tend to do non-optional parameters in one call, but then allow
additional calls for optionals. Languages without keyword=value syntax
do not do well for calls with large numbers of optional parameters.
In either case, when it comes to using the class months later, I prefer
to rely on Javadoc rather than memory.
Patricia
Hal Vaughan - 15 Jun 2007 05:03 GMT
...
>> I'm wondering if more experienced programmers have any experience or
>> comments that indicates whether a long list of parameters or a number of
[quoted text clipped - 5 lines]
>
> One consideration is whether the parameters have usable defaults.
That's a point I had not thought about. Thanks for making it.
> I tend to do non-optional parameters in one call, but then allow
> additional calls for optionals. Languages without keyword=value syntax
> do not do well for calls with large numbers of optional parameters.
I used to use Kate in KDE for all my programming. I'm self taught, other
than a few classes in BASIC and one in VAX 11/780 Assembler back in the
early 1980s, so when I had to start programming again, I was programming
for 4 years before I found out about an IDE. I'm using Eclipse and have
found it is a HUGE help when it prompts me when I'm typing out method
calls.
> In either case, when it comes to using the class months later, I prefer
> to rely on Javadoc rather than memory.
That was my thought and that I'd be better off with one call with the params
documented than having multiple calls and having to document the need to
make all the successive calls.
Hal
> Patricia
Tom Hawtin - 15 Jun 2007 03:53 GMT
> I have a situation where I will be passing one object to another so it can
> be configured and used internally. I could pass it with a number of
> parameters, probably 5 or 6, or I could pass it with only a few parameters
> and have all the rest specified with different method calls.
Or you could create an argument object. Call several methods on that to
set it up. Then use one call to apply those arguments.
Tom Hawtin
Roedy Green - 15 Jun 2007 10:16 GMT
On Thu, 14 Jun 2007 22:36:35 -0400, Hal Vaughan
<hal@thresholddigital.com> wrote, quoted or indirectly quoted someone
who said :
>I'm wondering if more experienced programmers have any experience or
>comments that indicates whether a long list of parameters or a number of
>different method calls tend to work better.
Shorter lists work better.
There is only one way to get the order wrong for 2 parms. For 3 parms
here are 5 wrong ways. For 7 parms there are 7!-1 = 5039 wrong ways.
You see how your odds of hitting the exact perfect order get worse and
worse as the number of parameters expands.
The problem is exacerbated when there are two or more parameters of
the same type without an obvious natural ordering. e.g. x,y
The one that nails me frequently is this:
new Font ("Dialog", 15, Font.BOLD);
It compiles just fine since Font.BOLD is an int, not an enum.
for other Font gotchas see:
http://mindprod.com/jgloss/font.html#GOTCHAS
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com