David Christensen wrote: > Steve Bertrand wrote: >> My question is, is if it is common practise to use named parameters >> for incoming arguments to functions/methods. > > I tend to code for personal, private use, so I have the luxury of > changing my mind as the mood suits me. I once saw a book with an apt > title -- "Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ > Programming". That said, finding, learning, and practicing conventions > is a never-ending, but beneficial, journey. There are way-points, but > there is no "ultimate" destination.
I agree. I also agree with Uri's 50-45-5 rule. However, coding is not my
primary job function. I engineer the network, so when I do my job
properly, I have huge amounts of paid time to do other productive
things, my favourite being programming in Perl.
I have hundreds of one-off scripts from over the years, but wanted to do
something better. Although I see my new large project being used in the
future, at this point, I'm open to making three changes a week to an
API, primarily so I can find my own coding style, and have some
consistency within my own code. Right now, I'm 10% plan, 70% code and
20% debug. Although I know what I want each method/function to do, I
don't know enough about all the different ways Perl can do it, so I'm
'playing' with the different options simply to learn.
I have found some benefit to having wildly changing API's... I've learnt
better ways to manage the callers to minimize impact, and better ways to
design parameter handling. I'm sure once I find my own style that
conforms (even loosely) to what other coders deem readable, I'll settle
so that API's are designed to not require change.
> I tend to use positional parameters if there is only one argument, or if
> there are a few arguments and their order is fixed:
>
> my $y = func($x);
> my $n = array_func(@a);
> my $m = point_func($x, $y);
>
>
> Otherwise, I use hash parameters (with CGI.pm style keys):
>
> my $e = func2(
> -foo => 1.23,
> -bar => ['a', 'b'],
> -baz => {-bozo => $x},
> );
>
>
>> is it recommended that a project should keep consistent with ALL
>> methods/functions in this regard whichever way one decides?
>
> Consistency is important, but you have to set boundaries and use your
> judgment. "One size fits all" hasn't worked for me.
>
>
>> I'm tired of trying to pop/shift error check the way I have been.
>> It's a nightmare when I want to add a new argument to an API, as it
>> immediately causes great (oftentimes subtle) havoc until I fix all of
>> the callers.
>
> The C library approach of putting error codes into function return
> values can work if the error code cannot be mistaken for a valid return
> value:
>
> system "$line"
> and die "$0 ERROR system '$line' failed: $!"
>
>
> I've thought about returning arrays and/or hashes with encoded errors,
> but haven't gone down that path.
The HOP (High Order Perl ;) book is absolutely fantastic for this sort
of thing, and it has completely changed the way I look at my own
applications (and I'm only on chapter 3!). For instance, done right, it
is VERY easy to front-end a method/function to do whatever you want
(param checking, error reporting etc). Because the param is passed in as
a coderef, you can 'plug-in' or unplug functionality into your already
functional functions, without changing a line of code.
>
> In general, I now use die() or some variant:
>
> use Carp;
>
> sub func3
> {
> ...
> confess "arguments must be hash"
> if (scalar @_) % 2;
>
>
> die() generates an exception outside of the normal flow of code, and
> eliminates the return value/ error code conflict. You can trap die()
> with eval():
>
> ### in a test script:
>
> $e = eval {
> func3("foo");
> };
> ok(!defined $e # 1
> && $@ =~ /arguments must be hash/,
> "call with single argument should fail",
> ) or warn Data::Dumper->Dump([$e, $...@], [qw(e @)]);
>
>
> It is possible to nest eval/ die, and "re-throw exceptions".
>
>
> There is also an OO exception handling module you may want to look at --
> Error.pm.
The majority of my time has been engineering a sanity and error checking
modules, which I've had a lot of fun with. However, I'm past the fun
part, and now want to get on with a consistent and easy to hook erroring
system. I'll have a look at what you've described.
> Learning and following conventions helps me when I use other people's
> code and vice versa. As the code becomes more complex, a simple and
> consistent coding style can mean the difference between success and
> failure. But, all this requires planning and effort. Whether or not I
> put out the effort depends upon who will be using the code and for how
> long. Short-but-sweet scripts and cryptic one-liners have styles unto
> themselves. And, there is a place for quick-and-dirty hacks. YMMV.
> TIMTOWTDI.
Thanks David. I guess what I was after originally was some feedback into
conventions. The one-offs to me are fine if I just slap them
together....but I'm now at the point where I'm trying to learn how to
make more functional, easier to maintain and easier to use code.
I think I've got a good start. API changes, here we come. Out with the
old, and in with dispatch tables and callbacks ;)
Steve
smime.p7s
Description: S/MIME Cryptographic Signature
