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.
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
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. 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@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com