Hi all, I've not had time to read all in this topic, then sorry if you already told about my problem. I got an error when going to the biblio_framework page in koha. "unexpected token (marc) [% grille marc %] at /home/users/koha/versions/community/C4/Templates.pm line 119." [% grille marc %] is simply the french tranlation of [% frameworkcode %] in the english template. I've modified the EN Template to add parenthesis around 'framwork' and it has not been translated to 'grille marc'. good. Then i think it would be better to do the same for each variables in each template but, strangely, in the same template, few lines later another [% frameworkcode %] has not been translated to [% grille marc %]. I don't know why ... Le 22/09/2011 19:42, MJ Ray a écrit :
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@koha:~/koha/unstable/src$ find . -type f -name '*.pl' | wc -l 966
coop@koha:~/koha/unstable/src$ grep -Erl '^.{79,999}' $(find . -type f -name '*.pl') | wc -l 937
coop@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,