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

[Lawrence Crowl <crowl at google dot com>]

On 6/27/12, Martin Jambor <mjambor@suse.cz> wrote:
> 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:
> > > > +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.

I am not concerned about private branches, but public branches for
which sharing might be needed, but for which cleanup before going
into trunk or a release is reasonable.

C++ streams are much more convenient for free-form output than
C-based solutions.  Having said that, does anyone object to removing
the permission to use C++ streams?

-- 
Lawrence Crowl