If I'm validating input, as in the example, I'm inclined to leave off the else. That's normally at the top of a sub, and I don't want to have the whole sub another level deep because it's all in else.

If it's more like a real branch, I might include the else. If the behavior changes so that the one branch does not exit, I want to be able to do that easily (i.e., without having to add the else).

I avoid using ternary operators for branching like this. I think of it as something that returns a value, so I don't like having it in a void context. If it's that important to save vertical space, I'd rather crowd my curlies than use a ternary.

if ( ! $sanity )
     { print "Mandatory happiness violated.\n"; exit }
else { print "You are happy.\n" }
[download]

...but even that I don't like much.

I'm generally of the opinion that code grows. Today's exit may be tomorrow's warn. The one line will be three. You should write it now to accommodate its growth later.

my $name = param("name");

# GOAL : ensure input values are valid

if ($name eq "")
{
   print qq(Sorry, name can't be empty);
   exit;
}

# CLAIM : all input values are valid

# GOAL : process input values

print "Thank you, $name. Your submission is complete.";
[download]

superfrink:

And that blank area between the CLAIM and GOAL is the perfect location for:

# CLAIM: all input values are valid
assert($name ne "");

# GOAL: process input values
[download]

(Yes, the exit above moots the assert in this case, but not all functions check all arguments.)

...roboticus

my $name = param('name');

if (defined $name && length $name) {
  # I prefer to test for the pass case rather than the fail.
  print "Thank you, $name, your submission is complete.\n";
} else {
  print "Sorry, name can't be empty.\n";
}

exit;
[download]

Your two examples and mine are all functionally equivalent, so it's just a matter of how the author likes to see things done. No worries.

Edit for clarity: I also tend to minimize the use of exit and/or die whenever possible, which is why I included the else in my example. I use length in case the user's name is 0e0 or some such nonsense.

That way the intent is obvious even when the introductory if() clause is scrolled off of the top of the editor window

For a counterpoint, from the same line of reasoning, I drew the opposite conclusion.

I put the shortest block in the if part, and the longer block in the else part, so the introductory clause is still visible in the editor window when you're reviewing the second part of the conditional. It becomes easy to say "yes, I'm here because that conditional just up there evaluated to false", because you can see it.

If both sections are so long as to not fit in the window, I'll probably wind up breaking them both out into separate subroutines, because, by definition, they're doing an awful lot of stuff.

Getting back to the OP, I'm a big fan of early returns, as it keeps the code closer to the left hand side of the screen. I'm a bit more leery of early exits. I dislike when some deeply buried routine decides it's time to stop the show (although END blocks can alleviate the problem of tidying up database connections and so on).

• another intruder with the mooring in the heart of the Perl

I put the shortest block in the if part, and the longer block in the else part, so the introductory clause is still visible in the editor window when you're reviewing the second part of the conditional. It becomes easy to say "yes, I'm here because that conditional just up there evaluated to false", because you can see it.

Interesting.

I just make sure the conditional as clear as possible, so I'll have if ( SomeCondition) { .. or unless ( SomeCondition ) { ..; then the blocks follow logically after that.

Under your guideline, my code

if ( SomeCondition ) {

  $this = 'that';
  $foo = 'bar;

  $quux{'quaz'} = [ $this, $that ];

  #  More code follows ..

} else {

  $this = 'the other';
}
[download]

would be rewritten as

if ( !SomeCondition ) {

  $this = 'the other';

} else {

  $this = 'that';
  $foo = 'bar;

  $quux{'quaz'} = [ $this, $that ];

  #  More code follows ..
}
[download]

I find that harder to read, because I would need to take the condition, reverse it, and then follow what's going on in the first block. For the second block, I'd have to go back to the original, un-reversed condition.

It's just not the way my brain works. ;)

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

I put the shortest block in the if part, and the longer block in the else part, so the introductory clause is still visible in the editor window when you're reviewing the second part of the conditional.

I try to do that too. I recall reading this guideline in a book about C ages ago. I don't adhere to it strictly, but if what I'm writing makes sense either way, I'll try to keep else as close to if as possible.

gloryhack's code looks a lot better to me. What I have to add: whenever there is some code that may or may not be executed, I want that to be clearly expressed in the code. Code in a block expresses that this code is subject to flow control. Djikstra said "although the programmer only makes programs, the true subject matter of his trade are the possible computations evoked by them"-- any time my code can clearly show the reader the possible computations, I will gladly take the trouble to add an else or another level of indentation. Functionally equivalent, yes, but to me as a programmer, this seems much better.
~dewey

Personally, I think it could be somehow a pathological case such as an implicit return from a sub, assuming you're just trying to avoid having following code executed; the exit; statement is fine though, if you explicitly want to exit. In former case, it works well, as long as you don't change anything - but, all of a sudden, it may break if you do (possibly triggered by removing/commenting the exit; statement accidentally).

As a side note:

If you're worried about the total size of the if {} else {} clause, you could give the ternary conditional operator (?:) a try (assuming your code doesn't continue below the ternary operator statement in this peculiar case):

($name eq "")
  ? print q{Sorry, name can't be empty}
  : print "Thank you, $name. Your submission is complete.";
[download]

If you're worried about the total size of the if {} else {} clause, you could give the ternary conditional operator (?:) a try (assuming your code doesn't continue below the ternary operator statement in this peculiar case):

($name eq "")
  ? print q{Sorry, name can't be empty}
  : print "Thank you, $name. Your submission is complete.";
[download]

(Sorry to reply so late but) this looks very wrong to me: the ternary operator is designed to operate on values, not to use it as a general purpose branching tool for its side effects. I would never do so except in golf: in particular the above example becomes perfectly fine if you amend it by factoring out the print:

print +($name eq "")
  ? q{Sorry, name can't be empty}
  : "Thank you, $name. Your submission is complete.";
[download]

$ARGV[0]?print "Thank you, $ARGV[0]. Your submission is complete.":do{
+print "Sorry, name can't be empty";exit;};
[download]

exit "Sorry, name can't be empty"
  if $name eq ''
;

print "Thank you, $name. Your submission is complete.";
[download]

UPDATE
I didn't know exit() was CORE:: -- news to me. use die instead as said below, I thought this was a user func.

You wrote

I would think this would be better:

exit "Sorry, name can't be empty"
  if $name eq ''
;
[download]

It's not, as per perldoc -f exit

exit EXPR
exit Evaluates EXPR and exits immediately with that value. Example:
...

Your code does exit 0 if $name eq '' which may or may not be what is intended, but what looks like a message being printed - isn't. Try at your shell

perl -e 'exit "foo"'; echo $?
[download]

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

For this kind of usage, with an error message, he should use die instead of exit.