> 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@xxxxxxxxxxxx ITC/Unix Systems flash@xxxxxxxxxxxx University of Virginia -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html