if you press the red button, the ejector seat will launch
[download]

the ejector seat will launch if you press the red button
[download]

if (the condition is more significant than what I do if the condition 
+is met) {
    use option C;
}
elsif (what I do if the condition is met is the interesting bit) {
    use option B;
}
else {
    probably use C on the same basis as [bjohnso];
}
[download]

This comment is dead on, to extend the metaphor

# check for a pilot action
if ($red_button_pressed) {
  eject_seat();
}

eject_seat() if $massive_failure; # check for exceptional behavior

# sub returns true/false if the seat was ejected
return $red_button_pressed && $massive_failure && 1; # fixed to put th
+e && 1 on the end, in the original it was at the start
[download]

The '1' is a perl-ism. Perl will return the value of the last true value in the boolean. To prevent people from taking shortcuts and expecting the sub to return false or the value of $red_button_pressed or $massive_failure we return one. Sooner or later it will no longer return what they think it does, and their code will melt (see also bitrot).

-jackdied

Your last bit of code confused me....

return 1 && $a && $b;
[download]

is identical to

return $a && $b;
[download]

is identical to

return 1 && 1 && 1 && $a && $b
[download]

So I don't follow your last paragraph...

Update
Were you perhaps thinking of:

return $a && $b && 1;
[download]

which will "coerce" all TRUE responses to be 1 instead of the value of $b?

-Blake

I have to admit that after 30 years of seeing Basic and Cobol programs structured

if  (cond)
  do something
else
  do something else
[download]

It may be prejudice that makes me prefer this structure. But I do think there is good reason too.

George_Sherston's comment about the relative importance of the things_to_do is a good one and I take this into account by making free use of unless() {}, but there's another issue here, for which I will put on my tester's hat. It is important that we see clearly that it is a condition. From the perspective of a test designer, the presence of a condition is more important that what it does. And since I think better code gets written if everyone who comes into contact with it thinks about it from a tester's perspective, that makes "C" style a clear winner for me.

BTW SInce I was using the "C" style a long time before C was invented, I find it hard to accept the phrase "traditional C style"!!

I personally use B, simply because it's succinct and easy to read, but doesn't bring in lesser-known quantities of the application.

If you're going to be working with less-skilled people, use C every time. The idea is to work with them, not show them how much you know (though demonstrating nicely new techniques is always reccomended ... especially for those times when you end up being charged for whitespace. *grins*)

------
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.

unless (a()){
 b();
}
[download]

b() unless a();
[download]

not use 'option_A' unless golf() or advanced_programmer();
[download]

  $_ eq $target && last foreach @value;
[download]

The second I like especially if the 'function' is a flow control keyword like next,last or redo or return. Also where there is no else and the if is expected to most often succeed, or on the contrary where I want to stylistically emphasize something. Like

  die "Whoa! Bad Majo" if $bad_mojo;
[download]

Oh yeah, if IIRC this type of stuff is covered in perlstyle quite nicely I thought.

HTH

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

  $debug && print "Some debugging output.\n";
[download]

  print "Some debugging output.\n" if $debug;
[download]

   if ($debug) {
      print "Some debugging output.\n";
   }
[download]

Good point you make here but let me mention one thing in the context of debugging in this way. If you make $debug a constant then you don't get any runtime speed penalty for these kind of tests. They are optimised away at compile time:

use constant DEBUG => 1;

DEBUG && print "printing debug info...\n";
print "printing other info ...\n";
[download]

Of course, you no longer have the option of specifiying your debug level on the command line. Sean M. Burke has a nice article about constants in perl (including this usage) here at The Perl Journal. We also had some discussion about that topic here at PM, e.g. in inlined DEBUG constant versus $DEBUG.

-- Hofmator

Option B is clean, but doesn't translate to English as clean as I would prefer. In general, I prefer the 'if' and 'unless' clauses after the statement only under rare circumstances. Because the statement is in front of the condition, the statement appears more important to the human mind. So, only use it when it is very likely that the code block WILL be run. For example:

print "Welcome, Mr. President." if from_whitehouse.gov();

instead of 

launch_nukes() if found_file("/bin/laden");
[download]

run_program() unless user_is_idiot();

open_file() or die;
[download]

print "Welcome, Mr. President"
{
  launch_nukes();
  send_ground_troops();
  enjoy_a_milkbone_in_a_commie_free_world();
}
unless password_failed();
#This can be bad. You have to read so many lines, get 
#confused, then go back and figure out where the block 
#began. Pain in the patukis.
[download]

if (expr)  {b()}
[download]

Again, keep in mind that this is all a matter of personal preference, and no one is right and wrong. Make your own code and goes with what makes the most sense to use. From my understanding of corporate coding jobs, their guidelines will take all that guess work out for you. :)

Toodles

I don't think its even valid to do a simple "BLOCK unless". However "do BLOCK unless" is valid.

do { 
  blah;
  blah;
  blah;
} unless 0;
[download]

-Blake

if (expr)
{
    b();
}
[download]

The more comments the better?

I strongly think not, and that is a gripe of mine.

Don't get me wrong. I use comments, and on the whole I have quite a few of them. But to me comments are something which has to be done right or else it is worse than useless, and I would prefer to see completely uncommented code to overly verbosely commented code.

For a thread that outlines my personal commenting style and the reasons for it at some length, I would suggest reading Re (tilly) 2 (disagree): Another commenting question,. (Note that behind the scenes we traded a series of /msgs that were more friendly than the discussion there.) After reading that, if you think that I really need more comments than I use, or that my points about how comments can be a problem are off-target, please give me feedback.

I beg to disagree with the statement "The more comments the better.".
Personally I state and restate:
"Any programmer of the language in question is supposed to understand what the code does."
"OTOH, you must document why the code does it."

This is especially important when the code makes assumption about the behaviour of external libraries or when the code depends on (more or less documented) side effects.

f--k the world!!!!
/dev/world has reached maximal mount count, check forced.

It's your choice: that's the beauty of Perl.

That said, I don't think I've ever seen the first version in use (although it's common with or aka ||). Of the other two, it depends on the complexity of the expression, the function call, and which you think is "more important", and you'd therefore like to read first in your code.

expr and b(); is good when the expr is more significant than the call to b(), or when you're emulating a switch statement.

b() if expr; is good when the call to b() is more significant than the expr, such as b() if $DEBUG;.

if ( expr ) { b(); } is good because it has the clearest structure, especially for people familiar with other languages.

--$option > ($i - 1) && $a = shift;
[download]

if ( expr )
{
    b() ;
}
[download]

I usually try to sound as English-like as possible, and keep in mind what I'm trying to emphasize: the test or the action? There's no One Right Way, even within the same program or even the same block of code. Go with what makes the most sense for the specific piece of code.

Also, consider the surrounding code. Something as simple as conditionally printing a phone number can depend greatly on why it's doing it. The "standard" way might be:

if ( $obj->show_phone ) {
    $obj->print_phone_number;
}
[download]

# Validate the phone according to basic U.S. rules
if ( $phone =~ s/^(1-)?(\d\d\d-?\d\d\d-?\d\d\d\d)$/ ) {
  $phone = $2;
  $phone =~ s/-//g; # Strip dashes
  $obj->set_phone( $2 );
} else {
  $obj->error( "Invalid phone number" );
}
if ( $obj->show_phone ) {
    $obj->print_phone_number;
}
[download]

But consider this instance where the context is entirely different.

$obj->print_name;
$obj->print_address;
$obj->print_phone_number if $self->showphone;
$obj->print_email_address;
[download]

Here, it's more appropriate to show that we're printing a bunch of information, and the phone number is optional. Writing it the "old way", with the phone number block taking three lines, would break up the visual flow, like so:

$obj->print_name;
$obj->print_address;
if ( $obj->show_phone ) {
    $self->print_phone_number;
}
$obj->print_email_address;
[download]

I think rule two of Perl, after TMTOWTDI, should be "It all depends."

xoxo,
Andy
--
<megaphone> Throw down the gun and tiara and come out of the float! </megaphone>

I would say what is most readable has to do with the "flow of thought" as to what you're doing. Perl is an "expressive" language in that you can say the same thing many ways.

My rule of thumb: It's readable if a person with a decent knowledge of Perl who is going bleary eyed debugging the program for the last 12 hours can still make sense of the code and not mis-read it, and if the code is clear enough that it requires minimal comments.

I usually avoid short-circuit expressions because they are often easily misread.

I would tend to go with option c (the traditional if structure) for the following reasons:

1. The vast majority of programmers - even non-perl programmers can (or should be able to) understand your intent.
2. If at some future time, you need to add some additional processing, you can slip another statement in without restructuring the code:

   if ( expr) {
       a(); # why didn't they think of this before?
       b();
   }
   [download]

3. (Updated)You can easily slip an else clause in there when someone realises that is required as well.

I frequently tend to use 'A', because I like it.
TIMTOWTDI !

f--k the world!!!!
/dev/world has reached maximal mount count, check forced.

Consider this nasty block:

my $arg = shift;

if ($arg eq 'one') {
    do_stuff()
}
elsif ($arg eq 'two') {
    do_other_stuff()
}
elsif ($arg eq 'three') {
    do_even_more_other_stuff()
}
else {
    do_yet_even_more_other_stuff()
}
[download]

my $arg = shift || 'DEFAULT';
my %lookup = (
    one     => \&do_stuff,
    two     => \&do_other_stuff,
    three   => \&do_even_more_other_stuff,
    DEFAULT => \&do_yet_even_more_other_stuff,
);

$lookup{$arg}->();
[download]

jeffa