Re: Format Style Opinions: my, ternary, subroutine

I no longer fear the ternary operator, so this is readable enough. There must be a clearer way to express the logic, though. Having the first parameter be undefined when @_ isn't quite long enough, and croaking if @_ isn't exactly the right length ... it makes my brain hurt a little.

What about switching around the order of the parameters?

sub xyz {
    my ($xxx, $yyy, $ttt) = @_;

    # You could also say -> if( !$xxx || !$yyy )
    # if you wanted to avoid 'unless' like the PBB says
    unless ($xxx && $yyy) {
        croak('Not good.');
    }

    # ...
}
[download]

This way we don't have to enforce a specific size for @_, too. Double bonus.

Comment on Re: Format Style Opinions: my, ternary, subroutine Download Code

Replies are listed 'Best First'.
Re^2: Format Style Opinions: my, ternary, subroutine by jffry (Hermit) on Dec 04, 2007 at 18:28 UTC
Wow. That is a simpler way to express it. Thanks. I think I'm still in that "everything is a nail" phase with the ternary op. However, I don't think it is wise to quietly keep going if a 4th argument is passed to it. I don't know about anyone else who might use this sub, but I certainly want to tell myself if I'm using it wrong.	[reply]
Re^3: Format Style Opinions: my, ternary, subroutine by webfiend (Vicar) on Dec 04, 2007 at 19:00 UTC
I understand your nervousness about extra arguments, but I've learned that they don't really matter in Perl. An analogy that comes to mind is filling a glass of water. If I hand you a cup and you pour a gallon of water into it, all I get back is a cup. I might make fun of you for being so sloppy, but who cares? After all, I have the cup of water that I wanted. Still, if it is important to you, you can enforce it with logic in your sub. `sub xyz { my $xxx = shift \|\| croak('Missing xxx parameter'); my $yyy = shift \|\| croak('Missing yyy parameter'); my $ttt = shift; # Enforce length of function parameter list. if (@_) { croak('Too many args for xyz!'); } # ... }` [download] ... but things like that risk making the code a little harder to read.	[reply] [d/l]


Problems? Is your data what you think it is?
	PerlMonks