[Koha-devel] tt style point

[MJ Ray]

Robin Sheat wrote:
> 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.

I dislike that publisher in particular, but also I'm a democrat, so
in general I'm against appointing Conway as a pope.  This discussion
should be about whether that book is correct, not who is the best
person to follow.

> > 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.

So is there no concise explanation of any of them?  If so, this must
be quite tenuous.

If someone could justify the bits where it's in conflict with Koha
perltidyrc/past practice, that would suffice.

[...]
> > 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 ;)

Oh niiiice, shoot the messenger because you can't justify it?

When I made parameter suggestions, I think I was trying to codify
current practice where it existed, as a starting point, but my memory
is poor and I don't have any relevant notes to hand.

Personally, I don't care what the maximum line length is, but I seem
to recall that some at liblime and biblibre used pretty wide windows
for coding, so there are some long lines in the code and I had
patches rejected when I split them.

[...]
> > 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. 

But, a and b) they understand others too (GCS being the obvious
alternative which would help open Koha up to non-perl and
multi-language programmers); c and d) no evidence of that has been
shown; e) is irrelevant because I'm not arguing against setting any
standard; f) seems like proof by appeal to authority, also creating a
divide between those who buy the ORA texts and those who do not.  (The
book is not in LibrariesWest and I'm not inclined to suggest my taxes
are spent on it.)

So at the moment, I think GCS with a few relaxations to avoid changing
old Koha code seems like the most logical standard.

Regards,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for various work through http://www.software.coop/