Op dinsdag 20 september 2011 04:18:02 schreef MJ Ray: > Probably. I dislike delegating this decision to an O'Reilly book
I prefer to delegate to Conway than some other arbitrary standard. The publisher is irrelevant. > and it would change some historic practices, so probably reformat > a lot of code. I think -pbp is equivalent to: > > -l=78 -i=4 -ci=4 -st -se -vt=2 -cti=0 -pt=1 -bt=1 -sbt=1 -bbt=1 -nsfs > -nolq -wbb="% + - * / x != == >= <= =~ !~ < > | & = > **= += *= &= <<= &&= -= /= |= >>= ||= //= .= %= ^= x=" > > but the perltidy man page doesn't say why those are best practices! Because you could fill an entire book with that, and that's too big for a man page. > They look as arbitrary as the GNU Coding Standards to me and rather > more invasive, but would anyone who has the book like to enlighten us? Each one is justified fairly well. For the one or two I disagree with (that I've found so far) I can see the rationale, I'm really just used to doing it another way. I'm not, however, going to write out everything, because that's a lot of effort for little gain. If you have a particular question, I'm sure I can answer it. > The Koha current perltidyrc conflicts with -pbp in that it has -l=178 > -ci=2 -bbt=0 -sfs -olq which disagree with the above. Of these, I think that each is "wrong", not because it's different to pbp, but because it hinders read/writeability. And -l=178? You must be kidding. That's terrible in-and-of itself. If I were to disregard something because of where it came from, this would be enough to make me disregard the rest of your suggestions ;) > suggested -bar -ce -bar isn't addressed in pbp (iirc), however -ce is in direct contradiction to it (this is something I'm not in total agreement with, but I'm willing to overlook it happily enough. I think my bias here comes from several years doing Java.) > which I don't think affects -pbp either way, -vt=2 > which agrees, -pt=2 which disagrees and -en=4 which doesn't even seem > to exist! -pt=1 (the default) is another where my usual way of writing differs, but I do find myself doing that in the more confusing constructs, which leads me to think that it's actually not such a bad idea. As for -en=4, that's almost as terrible an idea as -l=178. I'll pretend you didn't say it. > http://wiki.koha-community.org/wiki/Coding_Guidelines#To_be_decided > also specifies a capitalisation approach, -> for hashrefs and use of > ODLIS terms which I don't think perltidy can enforce. Again, I prefer the PBP method for naming. It's what (almost) every other Perl module does, and for fairly good reason. (Nutshell version: sub_name, $identifier_name, %title_of{$book_id}, @flowers, Package::Name, $CONSTANT) As for -> for hash/arrayrefs, definitely. > So, why would it be worth changing the line length limits, > indentation, outdentation, brace-tightness, and semicolon spacing to pbp? Because: a) it's a standard that many perl editors understand, b) many perl programmers understand, c) it's less arbitrary than any other standard (as the reasoning is quite meticulously backed up), d) it's a pretty good standard, e) if you don't pick a standard then the code will continue to be quite ugly, and this is one we have now without years of quibbling over where braces should go, f) many people have access to the book and so can read the justifications if they wish. There's probably more reasons I haven't thought of. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
