Developers of Sympa

[IKEDA Soji <address@concealed>]

Guillaume, sorry for delayed response.

On Mon, 11 Mar 2013 18:21:12 +0100
Guillaume Rousse <address@concealed> wrote:

> Le 08/03/2013 16:18, IKEDA Soji a écrit :
> [..]
> >> This lead to a mix of tabs and spaces which also a bad mixture on my
> >> opinion.
> >> I also disagree with the max line width of 78 columns. Most modern
> >> editors - even vi - are able to ad new lines if a line is too long. What
> >> is the rationale behind the 78 columns limit?
> >
> > I won't stick to mixing tabs and spaces: I'll regard consensus on use
> > of them.  In fact, PBP style won't use tabs at all (in .perltidyrc
> > above, items marked * are modified by me from PBP).
> >
> > Line width: To avoid unintentional line folding for all people
> > reading or writing codes, number of columns should be limited
> > (in particular, very long comment lines prevent readability).
> >
> > I think 78-columns limitation is appropriate.  Because it is
> > minimum column width that general termninals guarantee.
> >
> > I usually write codes using vi or emacs on 80x25-sized Gnome
> > Terminal, since it is most comfortable and fast way for me.
> The same for me. Automatic display wrapping by editor doesn't provide 
> the same visual confort than edit-time explicit insertion of end of 
> lines (which can also be automated, that's the 'textwidth' setting in 
> vim modeline).
> 
> >> All the rest is fine to me. Once we're OK with the pertlidy formatting,
> >> we can had an automatic perltidy execution somewhere (as a post-commit
> >> hook, for example).
> >
> > It's nice idea.  If agreeable .perltidyrc is given, I'll follow it.
> I remember reading than than modificating code server-side in a 
> post-commit hook was a very, very awful idea, because there was no way 
> for the server to notify the client he modified the submitted data... 
> Things may have changed, tough, as this was mainly a CVS issue.

I see...  If server automatically performs reformatting, uers will
have to checkout each commit of themselves!

> However, I'd still have heavy arguments against performing 
> non-supervised automatic reformating. Whereas perltidy, or any other 
> formatter actually (I personnaly use vim builtin formatting support), I 
> often add additional manual columns vertical alignment in many places 
> (functions calls, notably). I'd hate having some 'intelligent' tool drop 
> this kind of handcrafted final touch, just because 'it doesn't fit its 
> configuration'.
> 
> Having default formatting settings in perl source code file themselves 
> (the vim and emacs modelines), a default perltidyrc file at the project 
> root, and eventually indentation automated tests, such as 
> Test::Whitespaces (too bad this one hardcode its author preferences) to 
> report violations seems a far better idea for me.

Each of these may have advantage and disadvantage.
I suppose it is better to start with common .perltidyrc:
Committers may run perltidy over all sources anytime they feel
disunity; Unlike modelines, changes to single rc file affect
all.

Would you like to make up .perltidyrc not far from your formatting
rules?


> > And a comment to POD style by Guillaume: perlpodstyle manpage says
> > to use 'an "=item" for each interface'.  Almost all CAPN modules
> > also do it.  Sources in sympa-cleanup branch use "=head2".
> Well, currently we have something explicitely structured as:
> 
> =head1 FUNCTIONS
> 
> =head2 foo($bar)
> 
> =head3 parameters
> 
> =over
> 
> =item * $bar
> 
> =back
> 
> =head3 Return value
> 
> Something
> 
> =cut
> 
> Using enumeration for function/method names would force us to use 
> explicit depth level to each enumerations:
> 
> =head1 FUNCTIONS
> 
> =over
> 
> =item * foo($bar)
> 
> =over 2
> 
> =item + parameters
> 
> =over 4
> 
> =item - $bar
> 
> =back
> 
> =item + return value
> 
> =back
> 
> Moreover, given than we intricate documentation and code, this will 
> result in an opening tag =over in a first POD block, and its matching 
> closing =back tag in another at the end of the file, which seems a bit 
> curious.
> 
> Not than I'm really opposed to change my style (the =head3 level is 
> probably excessive), but I don't see much added value into flattening so 
> much.

Extra =over and =back is a small eyesore, but I don't mind.


Ragards,

--- Soji


> -- 
> Guillaume Rousse
> INRIA, Direction des systèmes d'information
> Domaine de Voluceau
> Rocquencourt - BP 105
> 78153 Le Chesnay
> Tel: 01 39 63 58 31
> 


-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/