qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: Proposed C++ style guide
Date Thu, 26 Oct 2006 11:12:39 GMT
As a long in the tooth C++'er, I like the proposed style guide.

I think point 11 is ok and used it myself on a v. big project with no ill
effects.  I like the fact that it prevents scope hiding of local variables
with private attributes.  Its better than having this.attribute everywhere
:-)

My preference is for block indent style #2 (flamebait!).
In fact I think that all blocks should be:

bla bla
{
    bla bla
}
else
{
    bla
}

I know people think its an aweful waste of space, but it's very consistent
and clear.

I agree that 4 space indenting is a must; and suggest everyone on the team
get this monitor immediately :-)


http://www.ubergizmo.com/15/archives/2006/02/dell_3007wfp_on_dell_2001fp_action_8_megapixel_desktop.html

Or the Apple 30'' cinema display.  2560x1600 coding heaven.

But I'm not coding the C++ broker, no it's just my 2c.

John


On 26/10/06, Gordon Sim <gsim@redhat.com> wrote:
>
> Alan Conway wrote:
> > With thanks to  Kim for finding it, I'd like to propose
> >
> > http://geosoft.no/development/cppstyle.html
> >
> > As the style guide for QPID C++ with the exception that Qpid continue to
> > use the .cpp file extension rather than .c++ It's not too far off the
> > existing style and it's largely in agreement with styles I've seen used
> > on other projects.
> >
> > Any objections?
>
> I don't like point 11 at all. The scope of a variable should be obvious
> without mangling the name. Leading or trailing underscores increase
> noise in my opinion and reduce readability.
>
> I also don't like 75 (& 81 which is more or less the same thing). The
> rationale seems weak to me and it reduces readability (in my opinion).
>
> I will be considering invoking points 1 & 2 in these cases!
>
> Perhaps I have bad eyesight, but I also much prefer 4 spaces of
> indentation. Maybe that is why 80 chars per line often seems to narrow!
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message