I suggest the following exceptions:
Point 11: (Private class variables should have underscore suffix) -
optional.
Point 34 (File names): We standardize on .h and .cpp
Point 37 (File content must be kept within 80 columns): 120 columns.
Point 71 (Basic indentation should be 2): 4 spaces instead of 2.
Point 72 (Block layout): We choose the ANSI style formatting/indenting:
namespace foo
{
int foo()
{
if (isBar)
{
doSomething();
}
}
} // namespace foo
I guess that only about half of the issues in this guide are addressable
through a formatting tool. The remainder (issues such as the naming of
variables) need to be checked manually.
As Steve Vinsoki has pointed out, emacs may be used in a batch mode to
help with formatting. Perhaps a script/config file which will achieve
the formatting/layout aspects of the guide can be checked into the tools
folder. Would someone who is familiar with emacs be able to do this?
Kim
-----------
On Thu, 2006-10-26 at 16:09 -0400, Alan Conway wrote:
> So far I have not heard any strong objections to using
> http://geosoft.no/development/cppstyle.html as a style guide.
>
> Two people have raised 4 space indenting and I'm inclined to agree.
>
> In the interests of avoiding endless debate on personal preference I
> propose we just live with it as-is with only those 2 exceptions: 4 space
> indents and .cpp file extensions. Making a long list of exceptions kinda
> defeats the purpose of picking a ready made style guide.
>
> If you _really_ hate it (and you actually plan to write some C++ code
> for qpid) propose an alternative ready-made, well-documented guide that
> suits your taste and we can vote on it. Or just use rules 1. and 2.
> extensively :)
>
> Cheers,
> Alan.
>
>
> Thu, 2006-10-26 at 10:04 +0100, Gordon Sim 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!
>
