[Koha-devel] tt style point

[Alex Arnaud]

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