in reply to The dreaded if-elsif-else construct (code)

This type of data-drive setup can drive a less-skilled maintenance programmer bonkers. I'm moderately skilled at Perl, and it took me several minutes, and most of the fingers on one hand, to puzzle out what you were trying to do.

Let me suggest an alternate approach. First get rid of the opendir calls by delegating to File::Find.

use File::Find; find(\&eachfile, "/data/");
and then structure the callback along the lines of
sub eachfile { my $path = $File::Find::name; return if -d $path; $path =~ s|^.*/(.+)_logs/|| or return; # or log my $item = $1; if ( $path =~ m|(.+)\.(\d+)$| ) { my($company,$quantity) = ($1,$2); inventory($company, $item, $quantity); return; } # and so on for each remaining case # eventually logging any that you can't handle }
That's the rough idea, at least -- it needs some cleanup and error handling.

This would seem to me to be a very easy thing for whoever comes along after you to understand and maintain. The most they would need to understand is File::Find, and that's a low hurdle.

Granted, this leaves you with the equivalent of a string if/elseif*/else, but it seems easy enough to follow.

Replies are listed 'Best First'.
Re: Re: The dreaded if-elsif-else construct (code)
by bastard (Hermit) on Nov 17, 2001 at 08:32 UTC
    One thing that could extend this approach and possibly eliminate the large quantity of ifs is to templatize the conditional.

    Set it up so that the test and actions are defined in a config file and work via a generic test/action method.

    Granted the performance will probably drop, but the maintainability should increase.

    There also might be modules that support this sort of templating of a function, but i haven't seen them yet. (as i haven't had the need yet)