Postfix conditionals and language design

[dougo]

So I'm reading some Perl code. I usually stay away from Perl as much as I can, but I'm trying to figure out some undocumented behavior of the MusicBrainz RDF server so I have to UTSL. Anyway, I get to this line:

      return ("No artist name or artist id given.", $data, 0, undef) 

and I get confused, because I saw the artist ID check but not the artist name check. So I start reading backwards to see if I missed something; maybe the artist name check happened in some non-obvious function call? I go skimming through various other files to see if some other code is filling in the artist ID or something. Eventually, I give up and come back to that line, and I notice that the next line is:

          if ($data->{artist} eq '');

and I smack my head. I'm willing to chalk this up to bad style (and I hope people would agree this is bad style), but now I'm wondering: when is it ever good style to put the conditional guard after the code it's guarding? Or, more generally, when is it ever good style for the order of code (in the same basic block) to be the opposite of the order of execution?

Comments

[petdance.livejournal.com]

On long things like that, I don't use the post-condition. But there are plenty of cases where it does make sense:

next if /^\s*#/;  # Skip comment lines

return 1 if $already_checked;

return unless $DEBUG;

warn "Invalid stooge" unless $stooge =~ /^(Moe|Larry|Curly|Iggy)$/;

The common metaphor of

open( my $fh, $filename ) or die "Can't open $filename: $!\n";

is just a post condition version of

if ( !open( my $fh, $filename ) ) {
    die "Can't open $filename: $!\n";
}

[mshonle.livejournal.com]

It's sad that "language designers" of the languages used today don't know much about language design. They (like Larry Wall and Guido Van Rossum) focus only on syntax, so they come up with dumb, experimental ideas of little importance (like that stupid, stupid tab crap in Python; and all of that conditional stuff in Perl). Moreover, these hacks completely miss "the good stuff" like lexically scoped closures (and not until many version later, likely from Scheme people demanding enough that they put in weak versions).

Python is particularly curious; from the get-go it had "lambda" but it was so horribly weak it was obvious the designer didn't even understand the languages he was so blantantly copying from. (I believe he copied from Ruby, which got closures in the Scheme sense right; which Ruby copied from Smalltalk).

At OOPSLA, the creator of Smalltalk, Alan Kay, said "My language represents an improvement, particularly among its successors". (He was quoting what was originally attributed to the creator of Algol.)

Alas, people like you and I who know better (i.e., know Scheme) are stuck with languages like Perl sometimes or Python/Zope. Meanwhile, the wonderfully designed languages like Dylan have no user base or libraries. I'd probably do a lot more web-programming if Dylan were somehow the language of choice for it.

[jfb.livejournal.com]

When is it ever good style to write perl?

[novalis.livejournal.com]

It probbably was originally shorter, such that it fit on one line. Then it would be better style (as noted in petdance's comment).

Quoting from the perlstyle man page

[daerr.livejournal.com]

Just because you CAN do something a particular way doesn't mean that you SHOULD do it that way. Perl is designed to give you several ways to do anything, so consider picking the most readable one. For instance

open(FOO,$foo) || die "Can't open $foo: $!";

is better than

die "Can't open $foo: $!" unless open(FOO,$foo);

because the second way hides the main point of the statement in a modifier. On the other hand

print "Starting analysis\n" if $verbose;

is better than

$verbose && print "Starting analysis\n";

because the main point isn't whether the user typed -v or not.