Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?

[H. Langos]

G'day J,

Thank you very much for the examples and the insights.
It's good to know that I'm not completely off with my 
novice's views of code style.

On Thu, Jul 02, 2009 at 10:30:04AM +1000, Jacinta Richardson wrote:
> This practice is called named arguments and is a great way of calling
> subroutines because it removes the confusion of which order the arguments need
> to go in.  It also allows you to set and use defaults, for example:

I hadn't looked at it from the angle of providing defaults. But it looks
very intuitive and robust. Until now I had defaults assigned one by one 
to "my" variables in sub routines and then optionally overwritten by the 
arguments passed in the $args_ref. Assigning them in one go is way more 
elegant.

>               state %defaults = (     # 5.10+ only, else "my %defaults"
>                       foo => 'a',     # or a closure
>                       bar => 'b',
>               );

"state" seems more or less equivalent to "static" in C. Nice feature.

>               $args_ref = { %defaults, %{$args_ref} };

I hadn't tought of that way to merge hashes. I wonder if it is usable for
subroutines that are called very often or if "unrolling" both hashes and
merging them this way is slower than conditionally assigning one by one.

    my $foo = 'a';
    my $bar = 'b';
    $foo = $args_ref->{foo} if defined($args_ref->{foo});

My first guess would be that merging the hashes is faster for bigger numbers
of arguments but slower if you are dealing with only a couple of arguments.
Anyway, I'll try both when the occasion arises and see what the profiler
has to say.

> It's not discussed in perlstyle, and perlsub because the maintainers of those
> files haven't really decided on a one-true way, or because they've been too 
> lazy
> to write it...  Damian Conway wrote bunch of good ideas about good Perl style 
> in
> his book called  Perl Best Practices, which is what most people point to when
> they talk about Perl style now.  These practices have been turned into
> requirements by the Perl::Critic system too, so you can get automated feedback
> on your code quality by using the Perl::Critic programs.

Thats a very good pointer. I'll try and see what Perl::Critic has to say about
the code in gnupod.

> 
> Hope this helps.
> 

A lot! Thank you very much. 

cheers
-henrik