my %Columns = (
    'label' => 0,
    'key' => 1,
    'cross' => 2,
);

foreach my $col_name (keys %Columns)
{
    $Columns[$col_name} = column_exists( \@data, $_[1] || $Columns{$co
+l_name} );
    die if $Columns{$col_name} == -1;
}
[download]

In addition, this lends itself to even further improvements. For example, consider

my %Columns = (
    'label' => {
        default => 0,
        exists => 0,
    },
    'key' => {
        default => 1,
        exists => 0,
    },
    'cross' => {
        default => 2,
        exists => 0,
    },
);

foreach my $col_name (keys %Columns)
{
    $Columns[$col_name}{exists} =
        column_exists( \@data, $_[1] || $Columns{$col_name}{default} )
+;
    die if $Columns{$col_name}{exists} == -1;
}
[download]

THAT is self-documenting code!

Furthermore, any time I see

do_A; do_B; do_C;
do_D;
do_A; do_B; do_C;
do_E;
do_A; do_B; do_C;
do_C;
[download]

for (\&do_D, \&do_E, \&do_C) {
    do_A; do_B; do_C;
    $_->();
}
[download]

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

i can't ++ and -- a node at the same time, and you have a high rep, so i just --'ed this one.

i like your first example of maintainable code. it could be extended further by variablizing the constant values, like

sub colNOEXISTS () {-1}

# and, then, in the for statement...
$Columns{$col_name}{exists} == colNOEXISTS 
    and die "your error here: $!";
[download]

what i don't like is your second example. i think it is difficult for a maintainer to understand that you're evaluating code references using a default variable, as in $_->() for \&do_A;.

secondly, the do_A; do_B; ... example could have been expressions or blocks, but your example limits do_C, do_D, and do_E to only evaluating code blocks. for instance,

$i=1; $j=2; $k=3;
$l = $i++ * $j++ for 1..$k;

$i=1; $j=2; $k=3;
$m = $j++ * $k++ for 1..$i;

$i=1; $j=2; $k=3;
$k=3;
[download]

(which is a somewhat contrived example) cannot easily fit into your method.

my point: zengargoyle suggested a formatting change to improve maintainability, while you suggested a functionality change. the formatting change is easy to implement and maintain, while your suggestion involves a deeper understanding of the underlying code, and the limitations of the construct which you impose upon it. i believe this has the potential to make code more difficult to maintain and extend, and has a higher potential to be misunderstood.

~Particle ;Þ

Heh. Thanx for the vote of confidence. You got a ++ ... :p

If you don't like $_->(), then use &{$_} instead. *shrugs* Six of one, half-dozen of the other. The point is that people are too afraid of code-references. They're one of the many reasons why Perl is so powerful.

As for the fact that do_A and do_B could be expressions or blocks ... That is a straw man. If you're doing the same code over and over, it should be a function. Plain and simple. I'm going to be stubborn here, but "The Rule"(tm) should be "Use a function for a piece of code that appears twice unless you have a good reason otherwise". Hence, if you initialize $i three times, there should be a function to initialize $i. What if you want to change what happens there, such as printing a debugging statement every time $i is initialized to 1? If it's broken out to a function, that's easy. If it's not, then it's nigh-unto impossible.

The point is maintainability, not ease of initial coding. Perl is very good in terms of reducing development time. Part of that is the ability to test out possibilities through one-liners and throw-away scripts. The other is the capability to write extremely maintainable code, in ways that other languages don't allow.

Remember - development is about 40% writing new stuff and 60% changing stuff that's already there. (I might even be overestimating the former.) If you can't easily change it, it's not reducing your development time. End of story.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.