Re: Is this bad coding style?

In addition to what bobf said, writing $_ == 1 is dangerous because it is too easy to drop an = and assign rather than compare. (Warnings will catch that, but you probably don't have warnings.)

Depending on the circumstances, where one person would use your approach I might have an array of references to closures. Then I just call them. Like this:

my @array = (\&do_where_var_is_1,\&do_something_else, \&do_something);
+ # etc
$_->() for @array;
[download]

This may look convoluted, but when you are building up your array in code it is as easy to put code references in as values, and now you don't have to synchronize between the if logic where you do stuff and the logic where you build the array.

Also this code snippet has very badly named variables, arrays and functions. Probably that is because it is an example, but do be sure that real code is of better quality.

Comment on Re: Is this bad coding style? Select or Download Code

Replies are listed 'Best First'.
Re^2: Is this bad coding style? by ikegami (Patriarch) on Jan 08, 2009 at 05:26 UTC
writing $_ == 1 is dangerous because it is too easy to drop an = and assign rather than compare. Some like to put constants on the LHS (`1 == $_`) to avoid that problem. `>perl -e"$_ = 0; die qq{uh oh!\n} if $_ = 1;" uh oh! >perl -e"$_ = 0; die qq{uh oh!\n} if 1 = $_;" Can't modify constant item in scalar assignment at -e line 1, near "$_ +;" Execution of -e aborted due to compilation errors.` [download]	[reply] [d/l] [select]
Re^3: Is this bad coding style? by tilly (Archbishop) on Jan 08, 2009 at 06:15 UTC
I swear that I meant to say that, and then I didn't. Thanks for saying it for me.	[reply]