Re: tt style point

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: tt style point

MJ Ray-2
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,
--
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
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: 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@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,

_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: tt style point

Colin Campbell-5
On 23/09/11 10:07, Alex Arnaud wrote:

> 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 ...
>
>
Its not a case of the bug reported as bug 6458?
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)
[hidden email]
skype: colin_campbell2

http://www.ptfs-europe.com
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: tt style point

paul POULAIN-3
In reply to this post by MJ Ray-2
Le 20/09/2011 13:40, Mason James a écrit :
>> > it is always the same question : who will decide
> we can decide now the koha-devel mailing-list, or as a topic for the next Koha IRC meeting
>
>
i've added the topic for the next IRC meeting
http://wiki.koha-community.org/wiki/General_IRC_Meeting,_5_October_2011#Agenda

HTH
--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Perl style point, was: tt style point

MJ Ray-2
In reply to this post by MJ Ray-2
I'm not sure this ever came back to this list, but the meeting
http://librarypolice.com/koha-meetings/2011/koha.2011-10-05-10.00.log.html#l-862
agreed to use perlstyle as the recommended perltidy config from now
on.

I've updated http://wiki.koha-community.org/wiki/Coding_Guidelines#Perl
but, returning to the original topic of this thread,
http://wiki.koha-community.org/wiki/Coding_Guidelines#HTML_Templates
could still do with a bit of expansion and linking to some tt resources.

Hope that helps,
--
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
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Perl style point, was: tt style point

Henri-Damien LAURENT
Le samedi 22 octobre 2011 à 18:09 +0100, MJ Ray a écrit :
> I'm not sure this ever came back to this list, but the meeting
> http://librarypolice.com/koha-meetings/2011/koha.2011-10-05-10.00.log.html#l-862
> agreed to use perlstyle as the recommended perltidy config from now
> on.
>
ok.... But is there a perltidy option to be sure to abide by this
"perlstyle"
Is "perl-style" the same as pbp ?
Is that the perltidyrc in our xt in src ?

> I've updated http://wiki.koha-community.org/wiki/Coding_Guidelines#Perl
> but, returning to the original topic of this thread,
> http://wiki.koha-community.org/wiki/Coding_Guidelines#HTML_Templates
> could still do with a bit of expansion and linking to some tt resources.
>
> Hope that helps,

--
Henri-Damien LAURENT
BibLibre

_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Perl style point, was: tt style point

MJ Ray-2
Henri-Damien LAURENT <[hidden email]>
> Le samedi 22 octobre 2011 à 18:09 +0100, MJ Ray a écrit :
> > I'm not sure this ever came back to this list, but the meeting
> > http://librarypolice.com/koha-meetings/2011/koha.2011-10-05-10.00.log.html#l-862
> > agreed to use perlstyle as the recommended perltidy config from now
> > on.
> >
> ok.... But is there a perltidy option to be sure to abide by this
> "perlstyle"

As I understand it, perltidy defaults to perlstyle, so just run it
with no options or rc file.

> Is "perl-style" the same as pbp ?

No.

> Is that the perltidyrc in our xt in src ?

No.

Hope that informs,
--
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
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Perl style point, was: tt style point

paul POULAIN-3
Le 24/10/2011 19:18, MJ Ray a écrit :
>> ok.... But is there a perltidy option to be sure to abide by this
>> "perlstyle"
>
> As I understand it, perltidy defaults to perlstyle, so just run it
> with no options or rc file.

Reminder: we've said during the last IRC monthly meeting that:
  * new code should be perlstyled
  * perltidying must not be done in a file mixed with other things
  * we don't perltidy everything for now, as it would result in git
blame returning the perltidy submitter as author of everything.

Side question : if someone has an idea to perltidy everything and not
loose the blame, he's welcomed. I've checked git blame --help, and it
seems we have a friend here :
       -w
           Ignore whitespace when comparing the parent’s version and the
           child’s to find where the lines came from.
except it's just for whitespace, and perltidy often update more than
space...

QUESTION/DISCUSSION =
I feel that just tidying new code will result in a mixing of style that
will be uncomfortable. OTOH, tidying everything would resuld in git
blame being unsusable.
It mean both situations are unsatisfying. Does anyone have an idea to
improve the situation ?

--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Reply | Threaded
Open this post in threaded view
|

Re: Perl style point, was: tt style point

Robin Sheat-2
Paul Poulain schreef op di 25-10-2011 om 10:37 [+0200]:
>   * perltidying must not be done in a file mixed with other things

What does that mean?

> I feel that just tidying new code will result in a mixing of style
> that
> will be uncomfortable.

I don't think that's a big deal. As sections get worked on, they'll get
tidier. The sections that don't get tidier are the ones that don't get
worked on and hence seen so often :)

--
Robin Sheat
Catalyst IT Ltd.
✆ +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D

_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Perl style point, was: tt style point

paul POULAIN-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 26/10/2011 00:36, Robin Sheat a écrit :
> Paul Poulain schreef op di 25-10-2011 om 10:37 [+0200]:
>> * perltidying must not be done in a file mixed with other things
>
> What does that mean?
It means the new code must be perltidyied, but old code must not be
perltidyed at the same time.

ie: your patches must do one thing only

This question is worrying me a little (just a little, really) I must
say. we will speak of during HackFest I think.


- --
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOp9NvAAoJEK81SonuhyGoqaYIAKoM+mFRJqAG4Yv2c5UlXoLe
GGPZyAaIdYhUkjtm14Af/saJ9sZq8daJNoG3Gbi3umdIEULcZfIUKVRBfjlE5NN3
DEfuqn8pQqhHczE34ClsxSikZlVy7/KaeiJDQsLXd12lpezD5xGCZXya0k8LIpIj
Vuh769NQTrv3MOFtsCj6NUpxDC5pdGP7rPayU529Fo4+k6NxyY4CoSxpjDTATBOO
x3HXuA65ddpIYS8HxxGai4sNmsQfAlY3CHT0FHdGCmhYSXG0FidumN3dhn1MJs54
0DCJlPHr4reNmN/GtAKPsNnEoRp5lTK0TrvURI6VRjnek3RWzTeVilpTrjrCL1A=
=acr2
-----END PGP SIGNATURE-----
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/