Developers of Sympa

[IKEDA Soji <address@concealed>]

Hi developers,

On Fri, 08 Mar 2013 11:18:37 +0100
David Verdin <address@concealed> wrote:

<<forgive me snipping some conversasions>

> > 2) finish to write current consensus (I'm volonteer for it)
> As far as I see, for now, we compromised on the followings:
> 
> Documentation:
> 
> =head1 CATEGORY
> 
> with section being either FUNCTIONS, CLASS METHODS or INSTANCE METHODS
> 
> =head2 prototype
> 
> with prototype being:
> - foo($var1, $var2, ...) for a function
> - Class->foo($var1, $var2, ...) for a class method
> - $object->foo($var1, $var2, ...) for an instance method
> 
> Description.
> 
> A plain english sentence.
> 
> =head3 Parameters
> 
> =over
> 
> =item * I<$var1>: purpose, nature
> 
> =back
> 
> =head3 Return value
> 
> A plain english sentence.
> 
> Code:
> 
>   * Move from new Object(...) to Object->new(...)
>   * Get rid of ampersands (&) at the start of subs,
>   * use perltidy. Soji suggested the following .perltidyrc:
> 
> ---------- >8 ---------------- >8 ---------------- >8 ----------
> -bar   # Opening brace always on right (* no)
> -bbt=1 # Medium block brace tightness
> -bt=2  # Medium brace tightness (* 1)
> -ce    # Cuddled else (* no)
> -ci=4  # Continuation indent is 4 cols
> -cti=0 # No extra indentation for closing brackets
> -et=8  # Entab leading 8 whitespace (* none)
> -i=4   # Indent level is 4 cols
> -l=78  # Max line witdh is 78 cols
> -nolq  # Don't outdent long quoted strings
> -nsbl  # No opening sub brace on new line (* -sbl)
> -nsfs  # No space before semicolons
> -pt=2  # Medium parenthesis tightness (* 1)
> -sbt=2 # Medium square bracket tightness (* 1)
> -se    # Errors to STDERR
> #-st   # Output to STDOUT
> -vt=2  # Maximal vertical tightness
> -wba="% + - * / x != == >= <= =~ !~ < > | & >= < = **= += *= &= <<= &&= -= 
> /= |= >>= ||= .= %= ^= x= || && . ? : and or xor"
> # Break after all operators (* not contains "||" and tokens appear after it)
> ---------- 8< ---------------- 8< ---------------- 8< ----------
> 
> 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.

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

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


Regards,

> anf inally, generally speaking, we want to have clear modules with 
> distinct usages, that can be independently tested and used, by I don't 
> see any way to formally phrase it.
> > 3) finish to enforce it everywhere
> With an iron fist if necessary.
> > 4) enlarge this consensus progressively, once easy issues such as 
> > syntax have been dealt with. For instance, we had a discussion about 
> > error management some times ago, without much result AFAIR.
> Indeed. To sum up my tohoughts: I don't want Sympa to die, but I want 
> errors to be cascaded from the point where the error occurs to the point 
> where tha calls started.
> >
> > Let's try some hazardous food-based metaphor: before trying to turn 
> > the whole plate of spaghetti we have now into something better, let's 
> > first convert it to a dinner table, where the appetizers, the starter, 
> > the main course and the desert are clearly separated and 
> > distinguishable from each others.
> And don't forget: once the table is set, let's all have a good beer 
> together!
> June in Montpelleir would probably be the good time and place for this...
> >
> > About my own personal coding style preferences, most of them are
> > summarized in the Perl Best Practices book, from Damian Conway 
> > (http://shop.oreilly.com/product/9780596001735.do) which is generally 
> > considered a reference in the Perl community.
> I ordered it...
> 
> Thanks for your input, Guillaume.
> 
> Best regards,
> 
> David
> >
> > -- 
> >
> >
> >   A bug in Sympa? Quick! To the bug tracker!
> >   <https://sourcesup.renater.fr/tracker/?atid=167&group_id=23&func=browse>
> >
> >
> >   David Verdin
> >
> > GIP RENATER - Direction Technique
> > Service applicatifs aux utilisateurs
> > Tél : +33 2 23 23 69 71
> >     RENATER logo <http://www.renater.fr>
> >
> >
> >


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