Re: [wwwdocs] Update coding conventions for C++

[Martin Jambor <mjambor at suse dot cz>]

Hi,

On Tue, Jun 26, 2012 at 11:06:15AM -0700, Lawrence Crowl wrote:
> On 6/26/12, Martin Jambor <mjambor@suse.cz> wrote:
> > On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote:
> > > > I have no idea.  I don't use emacs.  The two-space rule for
> > > > members comes from the wiki.  The one-space rule for protection
> > > > labels is common practice.  If folks want something else,
> > > > changes are fine with me.
> >
> > I'll also need an emacs C++ indentation style that conforms to
> > this in order to really be able to produce complying code myself.
> > So if anybody else will be working on that, I'm interested (to
> > use it and perhaps help crafting it) and I guess a number of
> > other people on this list are too...
> 
> Alternatively, one could change the conventions to match an emacs
> style.  Either is fine we me, as long as the style is reasonable.

That would be very nice :-) 
Of course, if many people do not find it reasonable, I'm sure there is
an easy way to tweak it.

...

> > > +but think twice before using it in code
> > > +intended to last a long time.
> >
> > I think all committed code should be expected to have long-lasting
> > quality.  I would not encourage people to think otherwise and would
> > drop the "long time" reference here.  If anybody ever commits
> > something ugly to bridge a short time period, it should only be done
> > under the "maintainers grant exceptions" rule anyway.
> >
> > > +</p>> +<p>
> > > +For long-term code, at least for now,
> > > +we will continue to use <code>printf</code> style I/O
> > > +rather than <code>&lt;iostream&gt;</code> style I/O.
> > > +For quick debugging code,
> > > +<code>&lt;iostream&gt;</code> is permitted.
> > > +</p>
> >
> > Similarly here, no quick and dirty debugging output should ever be
> > committed, we should not
> >
> > > +<h4><a name="stdlib">The Standard Library</a></h4>
> > > +
> > > +<p>
> > > +At present, C++ provides no great advantage for i18n.
> > > +GCC does type checking for <code>printf</code> arguments,
> > > +so the type insecurity of <code>printf</code> is moot,
> > > +but the clarity in layout persists.
> > > +For quick debugging output, &lt;iostream&gt; requires less work.
> > > +</p>
> >
> > The same applies here.
> 
> The value of these changes depends on when the rules are enforced.
> If they are enforced only on trunk, then the changes seem fine
> to me.  However, if they are enforced on branches, then they could
> unnecessarily slow down development.
> 
> Comments?

I think that if you have a private branch, you are basically its
maintainer and can grant yourself any exception from any rule you
want.  Of course, that might make your life harder if you later want
to contribute the changes to the trunk, release branches, other
peple's branches and generally anywhere.

Thanks,

Martin