Re: [MacPerl] Does Style Count? (formally, 'file tests')

[Jon Jacob and Joetta Moon <xavier@teleport.com>]

Xah Lee wrote:
> 
> The "predicate ? expression1: expression2" construct in Perl is not a
> mere syntax sugar. It differs from "if then else" because the former
> is an expression and the latter is not. More specifically, the former
> returns a value. In practice, this means one can do:
> 
> my $var = (predicate ? expr1: expr2);
> 
> but not
> 
> my $var = if (predicate) {expr1} else {expr2};
> 
> Of course, one can always write
> 
> my $var;
> if (predicate) ($var = expr1;) else ($var = expr2;)

I would actually write it:

if ($whatever)
	{
	    $var = expr1;
	}
else
	{
	    $var = expr2;
	}

You're telling me that the above is cumbersome?  Your way of doing it is
cumbersome for the next guy that comes down the pike is about as many
keystrokes.  (I bet it is as efficient, and I know it does the same
thing).  That is all I am saying.  I understand the general response
which is basically, "it is a useful tool, and has meaning so we should
learn how to use it."  Not all tools are useful or need to be used. 
There is a sort of arrogance floating around this discussion.  Some of
the points have been valid, but they mostly tend to fall into a general
tone which is that the desire to make something readable is not worth
the time or effort. 

> However, in non-trivial codes where a mere expression is needed in many
> places or nested tests, the
> latter can get very cumbersome and impractical. (the example above is
> only one situation where an expression is needed.)

IMHO, making code effortless to understand at a glance saves time in the
long run.  We seem to be stuck talking about this one operator, one I
will STILL never use, when I was hoping we could discuss some general
principles of style.  Issues such as variable naming, subroutine naming,
indentation, white space, commenting, and the like.

> Regarding "programing styles" as a matter how one format his code or
> syntax varieties, I
> think it is a energy drain and should be avoided. Instead, spend time
> studying the language constructs (aka ideoms), or even better:
> algorithms and CS theories.

Is my whole discussion pointless?  If so, I apologize, but I just have
had a recent series of run-ins with good Perl code that was not so easy
to read.  I make a decent living off of it, but I hope more people can
avoid it.  Novice programmers should be taught style, or at least
consistency, as more as algorithms.

> For large programs, readibility depends on one's knowledge of
> programing more than choice of syntax and code formating.

I gotta be direct here.  This is PURE arrogance on your part.  I don't
mean this as a flame, and I apologize if I offend, but I find this kind
of thinking unflattering to the rest of us.  Again I stress, just
because the code works, this does not make it good code.  All code even
good code needs to be updated and/or fixed.  Someone else is going to
have to do this to my code, your code, and everyone else's code.  We owe
it to the next group that come along to make their job easier so they
can make the most out of our hard work.

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch