[Koha-devel] tt style point

[MJ Ray]

Colin Campbell wrote:
> On 22/09/11 15:24, MJ Ray wrote:
> > 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.
> 
> The rationale for most of the formatting issues in pbp is that code
> should be consistent and that unless there is a good reason not to we
> should adopt the perl style guide ('perldoc perlstyle'). So most of the
> recommendations don't come from Damien or his evil publishers but have
> been distributed with perl for ages.

Past practices (the current perltidyrc) and making it easy for a
broader audience than just perl hackers (-gcs) both seem like good
reasons not to do it, but pbp is not the same as perlstyle (which
is the perltidy defaults).

[line length of 178]
> > 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.
> I agree wholeheartedly with Robin's point, although you might have lots
> of screen real estate its surprising how many tools for looking at code
> work better with a shorter line length and the extra real estate is
> probably more useful for running more windows. Too often the real import
> of a line might just disappear of the right edge... Plus its a handy
> reminder that your code might be becoming far too deeply nested so I
> think most coding standards irrespective of language gravitate towards
> an 80 col standard.

Those are whole debates in themselves, like whether short-line-only
tools are broken and whether it's healthy to restructure code mainly
to reduce nesting, but I suggested 178 because coders were using it.

If I've got these command right, they still seem to be:

coop at koha:~/koha/unstable/src$ find . -type f -name '*.pl' | wc -l
966

coop at koha:~/koha/unstable/src$ grep -Erl '^.{79,999}' $(find . -type f -name '*.pl') | wc -l
937

coop at koha:~/koha/unstable/src$ grep -Erl '^.{79,178}' $(find . -type f -name '*.pl') | wc -l
937

So I think about 97% of .pl files would be changed by just that one
setting change.

I'd love to hear if many use 178-columns now, especially at biblibre
and liblime because I think it came from one of them.

> > 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); 
> As far as GCS is concerned perltidy's man page points out that "-gnu
> approximates to the Gnu Coding Standards (which do not apply to perl) as
> they are sometimes implemented" Not really a resounding vote in favour.

Well, they're written only for C, but it's a pretty trivial
translation to most languages and they're less Perl-specific.

> > [...] proof by appeal to authority, also creating a
> > divide between those who buy the ORA texts and those who do not.
> It's not about the book, almost all the formatting recommendations come
> from the documentation which has always come with perl. It also is a
> style which does not jar with the bulk of good code you'll find in CPAN
> and elsewhere.

It does jar with the bulk of Koha, much of which is also good code in
other ways, isn't it?

The Koha community never followed the perlstyle recommendations,
they're not new and I'd like to think that our predecessor coders had
their reasons for what they did (I don't know if Chris C knows why but
I think it was on Josh's watch), so I feel there needs to be a decent
reason for such a wide-reaching change.

> For rationales of some of the recommendations and other good suggestions
> folk might want to look at
> http://onyxneon.com/books/modern_perl/
> which is free in its electronic form.

I'll take a look at that.  It may take some time.  PDFs aren't fun.

> One of the points made there is that following community norms unless
> theres a real reason to differ is good because the community builds
> tools which leverage those norms. perltidy is an example, I think if you
> compare the defaults with the pbp recommendations they are identical for
> most settings

perltidy's defaults are perlstyle, not PBP.

Following community norms is a great idea!  *Which* community norms?

We've at least four norms to choose between here: Koha, GNU, Perlstyle
and PBP.  PBP seems the least accessibly documented of them all and I
don't think any formatting can be brilliant enought to outweigh that
barrier - and I don't think a restricted book like PBP is really a
*community* norm either.

Regards,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and LMS developer, statistician.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha