You could have written the original loop as:

for (map("arg$_", 1..5)) {
  ..
}
[download]

  foreach ( @formArgs ) {
    ..
  }
[download]

<aol>me too</aol>

And to take this a bit further, if there's no else, I'd write this like so:

for (map("arg$_", 1..5, 19), "gee37") {
    $object->method($_) or next;

    # ...
}
[download]

Fewer indentation levels are generally easier to read. Finding this at the bottom of a function always makes me scroll up and down a couple times:

                                   # ...
                              }
                        }
                  }
                  # play "guess the block this belongs to" here
                  $_ .= "something";
            }
      }
}
[download]

Makeshifts last the longest.

Is there a reason that the idea merlyn mentioned (that I think is a excellent use of perl) was comprehensively glossed over?

I'd also try and do away with the if block but I think cond or next; reads a little unintuatively and would probably use
next unless cond;

for ( 'arg1' .. 'arg5', "arg19", 'gee13' .. 'gee37' ) {
     next unless $object->method( $_ );
     # do stuff
}
[download]

---

Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!

It depends on what I want to emphasize: I use EXPR or next; when a failure at that point is the exception. Of course, looking back at the original poster's code, there's nothing that says it is - and if not, I agree, I'd use a next if. I do so 95% of the time anyway. The flexibility of Perl's syntax allows a natural way of conveying emphasis, and I try to make use of that when appropriate. "Self explanatory" is usually my top goal.

Makeshifts last the longest.

To me, it seems that your approach is working against this maxim. You are embedding the irregularities in the code. Sure, they are data in the code, but you have to work out that fact because you build up a list of 1-5 and 19 and attach gee37 to the end of it.

I think that this:

@obj_args = qw/ arg1 arg2 arg3 arg4 arg5 arg19 gee37 /;
for ( @obj_args ) {
   ...
}
[download]

Is clearer. In this example, you've clearly separated the irregularities into a data structure and used that to drive the code.

This kind of separation has all kinds of maintenance advantages, not just clarity on first reading. Say the maintenance programmer is confronted with a case where the arguments arg3 and gee37 have strange behavior. It's easy to change the code for this and you're doing it in such a way as to make it very clear if someone else working with the maintenance programmer would immediately grasp the intent.

I much prefer:

# @objargs = qw/ arg1 arg2 arg3 arg4 arg5 gee37 /;
# 
# test just arg3 and gee37
@objargs = qw/ arg3 gee37 /;
for ( @objargs ) { 
  ...
}
[download]

To this:

#for (map("arg$_", 1..5, 19), "gee37") {
#
# test just arg3 and gee37
for ( qw/ arg3 gee37 / ) {
  ...
}
[download]

This shows how the irregularity of the data is more clearly separated from the code. When you use something like:

(map("arg$_", 1..5, 19), "gee37")
[download]

You are using code to represent the irregularity of the data.