From: Bill Pemberton <wfp5p@viridian.itc.virginia.edu>
Date: Wed, 29 Apr 2009 19:48:51 GMT
Subject: Re: [PATCH 0/6] cleanups for git-send-email
Message-ID: <20090429194852.0976257034@viridian.itc.Virginia.EDU>
In-Reply-To: <7vws939skl.fsf@gitster.siamese.dyndns.org>

> Perl styles are highly personal.
> 

So are C styles, but the kernel and git doesn't allow all sorts of
mixed styles.  My changes are also not just coding style, they have
actual meaning in perl.

My changes come directly from the book "Perl Best Practices".  Just as
you do things like "don't allow assignment in conditionals" in C, even
though it's legal.  There are good reasons to do these things in perl
to prevent bugs down the road.

> 
> *1* ...except for the "and/or vs &&/||" bits, even though I prefer the
> latter myself solely because I am old fashioned.
> 

Again, it prevents bugs.  People use "and" vs "&&" as the same thing,
when they are not.  The have different precedence in perl.

For example, 

next if not $finished || $x < 5;
next if !$finished || $x < 5;

do not mean the same thing.


> I think it is simply silly to say "precedence of ! and and/or does not
> mix".  "!" and "&&" have different precedence and rewriting (A and !B)
> into (A && !B) would not make things any better nor worse.  After all,
> nobody would have problems with "$a + $b * $c" even though + and * have
> different precedence.
> 

It's not that ! and && have different precedence.  It's that "not" and
! have different precedence.  Using your math example, it would be
like having an operator named plus that had a higher precedence than
"*".  Now if you wrote "$a plus $b * $c" it would have different
result than "$a + $b * $c".


> Oh, I also do not agree with "always explicitly return".  If the change
> and explanation were limited to the subs whose return values are _used_, I
> would agree with the change, though.
> 

Again, it prevents potential bugs down the road.  Currently those
functions return something.  While they are not used, the something
they return can be interpreted by developers as an intentional return
value and that property may get used.  If some other developer changes
the original function in some way that the implicit return becomes
something else, it'll create a bug.  If a subroutine isn't supposed to
return a meaningful value, it should do it explicitly.


-- 
Bill Pemberton                                 wfp5p@virginia.edu
ITC/Unix Systems                               flash@virginia.edu
University of Virginia