[Koha-devel] tt style point

[Robin Sheat]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/koha-devel/attachments/20110920/51c1167d/attachment.pgp>