Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Re: Poor Man's Prototyping?

by edebill (Scribe)
on Nov 25, 2001 at 19:27 UTC ( [id://127386] : note . print w/replies, xml ) Need Help??


in reply to Re: Poor Man's Prototyping?
in thread Poor Man's Prototyping?

I'd even nuke the shift. I replace:

sub dosomething{ my $foo = shift; my $bar = shift;

with

sub dosomething{ my ($foo, $bar) = @_;

That gets all the args and their order right up on the first line of the sub, where it's easier to see. I tend to agree with the Linux kernel CodingStyle document when it says that if you have more than 2-3 args there's probably some re-factoring in order. Cutting and pasting your function calls just seems... icky.

Replies are listed 'Best First'.
Re (tilly) 3: Poor Man's Prototyping?
by tilly (Archbishop) on Nov 26, 2001 at 02:47 UTC
    This is something I would call a matter of personal taste. I talked about it at Silly code reviews and shift, and as I said there, it certainly is common to find shift used in argument processing in core modules, CPAN, etc. I have personally tried it both ways.

    My current opinion is that whether or not using shift for processing or assigning in one line is better is dependent on the rest of your coding style. As my style has changed it has gone from being definitely better to shift to (currently) being essentially indifferent.

    Furthermore on named arguments, I agree that long argument lists maintained by argument order are a bad idea. But I do not agree that the Linux kernel CodingStyle applies directly to Perl. In particular in Perl it is often very good style to develop list-based functions which may easily have 10 or 1000 arguments. And often you want to provide various kinds of optional default behaviour. In which case, as suggested in the root node, I find it best to provide a named parameter style with reasonable defaults where appropriate. Typically the calls will either wind up (at least in my code) being a pass-through hash, or else I will just use a few of the possible options in any particular code.

    Try it. It may take some time to be able to take good advantage of the flexibility offered. But I think that knowing how and when to do that is a good tool to put in your toolbox for languages that give you a way to do it.

      Typically the calls will either wind up (at least in my code) being a pass-through hash, or else I will just use a few of the possible options in any particular code.

      In which case you're really only passing a single arg - the hash ref :-)

      I still think it's better to pass  foo($bar, $baz, \@quux) and then operate on the array ref than  foo($bar, $baz, @quux) and shift through the last args. If nothing else it'll be faster to call by reference.

      But really, my complaint is for things like:   $newhash = session::create_hash($sha, $userid, $come_from, $go_to, $sessionid, $time, $hash_secret); which could very well benefit from not having to pass in things which are almost always constant ($sha and $hash_secret), and which could be turned into an object and reduced to

      $newhash = $session->create_hash($come_from, $go_to, $time);

      which is much more readable.

      and yes, $time would be an optional argument -

      sub create_hash{ my ($self, $from, $to, $time) = @_; unless($time){ $time = time(); }

      variable argument lists - where all the args are basically the same thing to operate on are no problem. It's when you have lots of args which are all required (and different) that the sub gets really hard to use. Trying to remember 12 arguments, all of which are required just isn't going to work. Even if you do named arguments. On the other hand, I do agree that named args might be useful for optional args.

        I said I was passing through a hash, and you assumed that I was passing through a reference to a hash?

        Bad assumption.

        I pass through a list of key/value pairs, and construct the hash inside of the function. Why? So that I can then proceed to do destructive processing on said hash without bothering my caller. Furthermore it allows the easy setting of a few optional defaults in a wrapper function:

        sub some_wrapper { # Do some wrapper type stuff here. real_function( key1 => $default1, key2 => $default2, @_ ); }
        But you cry about efficiency! I respond, So what? If my code is performance critical, I will worry about performance. Usually it isn't, and I will worry about my sanity first, second, and fourth. (Third is other people's sanity or lack thereof.)

        As for your complaint, true. In languages where arguments are positionally placed, more than 2-3 arguments gets cumbersome. I find that with named arguments the average person's threshold goes up. 5-6 arguments is not problematic. Our name association goes father than the memorization of orders of arguments, and the type of error changes from messing up argument order (hard to catch) to typos (which I place automated checks for). And people who can consult documentation are extremely tolerant of large numbers of possible optional arguments, just so long as they are pretty much independent.