Hi--
On Apr 6, 2010, at 6:21 AM, Randal L. Schwartz wrote:
>>>>>> "RW" == RW <rwmailli...@googlemail.com> writes:
> RW> Imperative languages have a natural order of decision followed by
> RW> action, and code is most easily readable if the syntax doesn't try to
> RW> subvert that.
>
> And yet, there's an equally valid argument that the most important
> thing should stand out the most. In that sense, in the Perl statement:
>
> warn "x = $x, y = $y, z = $z\n"
> if $debug;
>
> ... the most important part is that it's printing something to stderr,
> and what's being printed. It's only minor that it's only when
> debugging, and luckily Perl lets us relegate that to the tail end of
> the statement.
>
> Now, if you argue "oh, the most important thing there is 'if debug'",
> then fine, you'd write that as:
>
> if ($debug) { warn ... }
>
> And I'd be fine with that.
Let's suppose you want to display one message if debugging is enabled, and a
shorter message if it is not. Adding an else clause to an if statement is a
natural change and the result remains highly readable. Can one even use this
postfix test syntax with an else, or would you have to re-write the first
version entirely?
As far as I am concerned, the first version resembles exception handling, ie:
try:
<something>
except Error1:
<handle error>
...and should be reserved for situations where the statement is expected to run
normally. If it is reasonable that the test might fail more often than in
unusual circumstances, then I'd really prefer to put the test first.
> If you don't like all this freedom, there's always Python. :)
Yes, Perl lets you innovate a remarkable number of ways of solving the same
problem using syntax that varies from clean and maintainable to constructs
which even the original author won't understand without effort a few months
later. It seems to be uncommon for one to write unreadable Python code; I'm
not sure additional freedom to write obfuscated code would be as beneficial as
one may assume....
Regards,
--
-Chuck
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
