[Koha-devel] tt style point

Colin Campbell colin.campbell at ptfs-europe.com
Thu Sep 22 17:59:31 CEST 2011


On 22/09/11 15:24, MJ Ray wrote:
> 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.

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.

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

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

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.
The purpose of PBP was to encourage people to think about writing
robust, maintainable code. If folks want to see what the recommendations
were (unfortunately minus the rationale) see:

http://refcards.com/docs/vromansj/perl-best-practices/refguide.pdf

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

C.

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 845 557 5634 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com


More information about the Koha-devel mailing list