Developers of Sympa

[Guillaume Rousse <address@concealed>]

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.

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.

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

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

Attachment: smime.p7s
Description: Signature cryptographique S/MIME