Re: Coding styles using if/else

I tend to use else (in these kinds of very simple cases) when the block before it occupies much in the way of vertical space in the editor window, but often exclude it when the preceding block is brief. That way the intent is obvious even when the introductory if() clause is scrolled off of the top of the editor window. If I was doing that test, it'd be:

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.

Comment on Re: Coding styles using if/else Download Code

Replies are listed 'Best First'.
Re^2: Coding styles using if/else by grinder (Bishop) on Apr 06, 2007 at 11:41 UTC
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	[reply]
Re^3: Coding styles using if/else by talexb (Chancellor) on Apr 06, 2007 at 17:23 UTC
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	[reply] [d/l] [select]
Re^4: Coding styles using if/else by jdporter (Paladin) on Apr 06, 2007 at 18:27 UTC
What's all this if/else business? `( sub { # false $this = 'the other'; }, sub { # true $this = 'that'; $foo = 'bar; $quux{'quaz'} = [ $this, $that ]; # More code follows .. } )[ SomeCondition ]->();` [download] :-) :-) :-) :-) :-) :-) :-) :-) A word spoken in Mind will reach its own level, in the objective world, by its own weight	[reply] [d/l]
Re^3: Coding styles using if/else by kyle (Abbot) on Apr 06, 2007 at 18:01 UTC
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.	[reply] [d/l] [select]
Re^2: Coding styles using if/else by dewey (Pilgrim) on Apr 06, 2007 at 05:35 UTC
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	[reply]