C++ Guidelines

[Pete Vidler]

Hi Folks,

I'm wondering if there is a compilation of C++ guidelines out there
anywhere. Here are some of the ones I've picked up so far (as examples):

- Functions should fit on one screen, from various sources.

- Non-leaf classes should be abstract (have pure virtual methods), from
More Effective C++, Item 33.

- Virtual methods should be private by default and protected if they
need access to a base classes version (except for the destructor, of
course), from http://www.gotw.ca/publications/mill18.htm.

- Header files should be self contained, from various sources.

- Destructors for base classes should be either virtual or protected.

I think I've probably missed (or never heard of) quite a few more.
Anyone know where I can find such things? Or have some guidelines of
their own to share?

-- Pete

[Pete Vidler]

Claudio Puviani wrote:
[snip]

http://search.barnesandnoble.com/boo...sbn=0521893089

It's basically an extension of what used to be Rogue Wave's guidelines. No
one will agree with every guideline, but they're mostly reasonable.

Interesting.. but the summary says it deals with formatting, naming,
documentation, etc. I was looking for design guidelines along the lines
of those that I posted. Am I correct in assuming it doesn't cover such
issues?

- Functions should fit on one screen, from various sources.

That's really a side-effect of a few more fundamental principles, such as
"maximize cohesion" and "modularize where reasonable." A function that is
very large should raise flags, but there are rare instances where it's
entirely justified to have even extremely large functions (as anyone who's
ever used YACC will testify).

Yes that example was more basic than I really wanted. Ignore it, I'm far
more interested in guidelines similar to the others that I posted.

- Header files should be self contained, from various sources.

This one should be shredded or rephrased. Header files have dependencies
just like any other software component, and so can rarely be self-contained.

[snip]

Obviously if a header file is from a library then the library must be
linked to. I meant from a compiler point of view.

More specifically that it should forward declare or #include everything
it requires to compile. I'm fairly sure most people would understand
this from "self contained", but I suppose I should have been more precise.

-- Pete

[David Harmon]

On Sat, 10 Apr 2004 16:16:23 +0100 in comp.lang.c++, Pete Vidler
<pv*****@mailbl ocks.com> wrote,

This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>

Most of the links there appear to be documents detailing naming
conventions and recommending a given style for the placement of braces.
I'm looking for more along the lines of design guidelines like I posted

Well, arguing over the placement of braces has less potential for harm
than many of the design guidelines I have seen.

[David Harmon]

On Sat, 10 Apr 2004 16:16:23 +0100 in comp.lang.c++, Pete Vidler
<pv*****@mailbl ocks.com> wrote,

This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>

Most of the links there appear to be documents detailing naming
conventions and recommending a given style for the placement of braces.
I'm looking for more along the lines of design guidelines like I posted

Well, arguing over the placement of braces has less potential for harm
than many of the design guidelines I have seen.

[Pete Vidler]

David Harmon wrote:
[snip]

Well, arguing over the placement of braces has less potential for harm
than many of the design guidelines I have seen.

Yes, but there's no potential for learning anything with
brace-placement. You can already see the possibilities.

-- Pete

[Pete Vidler]

David Harmon wrote:
[snip]

Well, arguing over the placement of braces has less potential for harm
than many of the design guidelines I have seen.

Yes, but there's no potential for learning anything with
brace-placement. You can already see the possibilities.

-- Pete

[Daniel T.]

Pete Vidler <pv*****@mailbl ocks.com> wrote:

Daniel T. wrote:
[snip]

Check out these two books:
"Large-Scale C++ Software Design" by John Lakos

I've heard of this one, but isn't it seriously out of date? I've also
heard that he has some strange guidelines like not using namespaces?

"Object-Oriented Design Heuristics" by Arthur J. Riel

I'll look into it, thanks.

This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>

Most of the links there appear to be documents detailing naming
conventions and recommending a given style for the placement of braces.
I'm looking for more along the lines of design guidelines like I posted
(there was one good page there though, thanks).

I don't really need the basic stuff (I know most of them), but I am
looking for more advanced guidelines (with justifications, like the one
about making virtual methods private).

Try the articles at this site:
<http://tinyurl.com/2tt4h >

[Daniel T.]

Pete Vidler <pv*****@mailbl ocks.com> wrote:

Daniel T. wrote:
[snip]

Check out these two books:
"Large-Scale C++ Software Design" by John Lakos

I've heard of this one, but isn't it seriously out of date? I've also
heard that he has some strange guidelines like not using namespaces?

"Object-Oriented Design Heuristics" by Arthur J. Riel

I'll look into it, thanks.

This site may also be helpful:
<http://www.chris-lott.org/resources/cstyle/>

Most of the links there appear to be documents detailing naming
conventions and recommending a given style for the placement of braces.
I'm looking for more along the lines of design guidelines like I posted
(there was one good page there though, thanks).

I don't really need the basic stuff (I know most of them), but I am
looking for more advanced guidelines (with justifications, like the one
about making virtual methods private).

Try the articles at this site:
<http://tinyurl.com/2tt4h >

[Steven T. Hatton]

Pete Vidler wrote:

David Harmon wrote:
[snip]

Well, arguing over the placement of braces has less potential for harm
than many of the design guidelines I have seen.

Yes, but there's no potential for learning anything with
brace-placement. You can already see the possibilities.

-- Pete

This looks like food for thought. I'm not endorsing, just passing it on:
http://www.possibility.com/Cpp/CppCo...ndard.html#cuh

You may already be aware of this. It's general, but certainly has a link or
five that will be relevant:
http://www.fz-juelich.de/zam/cxx/extmain.html
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Steven T. Hatton]

Pete Vidler wrote:

David Harmon wrote:
[snip]

Well, arguing over the placement of braces has less potential for harm
than many of the design guidelines I have seen.

Yes, but there's no potential for learning anything with
brace-placement. You can already see the possibilities.

-- Pete

This looks like food for thought. I'm not endorsing, just passing it on:
http://www.possibility.com/Cpp/CppCo...ndard.html#cuh

You may already be aware of this. It's general, but certainly has a link or
five that will be relevant:
http://www.fz-juelich.de/zam/cxx/extmain.html
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Claudio Puviani]

"Pete Vidler" <pv*****@mailbl ocks.com> wrote

Claudio Puviani wrote:
[snip]

http://search.barnesandnoble.com/boo...sbn=0521893089
It's basically an extension of what used to be Rogue
Wave's guidelines. No one will agree with every
guideline, but they're mostly reasonable.

Interesting.. but the summary says it deals with formatting,
naming, documentation, etc. I was looking for design
guidelines along the lines of those that I posted. Am I
correct in assuming it doesn't cover such issues?

It has rudimentary design guidelines as well. The formatting section is just
a few pages, and the least interesting at that.

Here's a list of books I posted once before that would give you what you
need:

For general inheritance guidelines, strategies, pitfalls, etc. (in no
particular order):

"C++ Primer" by Lippman and Lajoie
"Effective C++" by Scott Meyers
"More Effective C++" by Scott Meyers
"Effective STL" by Scott Meyers
"Exceptiona l C++" by Herb Sutter
"More Exceptional C++" by Herb Sutter
"Large Scale C++ Software Design" by John Lakos
"Designing and Coding Reusable C++" by Carroll and Ellis
"Rumination s on C++" by Koenig and Moo
"Enough Rope to Shoot Yourself in the Foot" by Allen Holub
"C++ Strategies and Tactics" by Bob Murray
"C++ Programming Style" by Tom Cargill
"C++ in Action" by Bartosz Milewski
"C++ Code Capsules" by Chuck Allison
and even the old but excellent "Advanced C++" by James Coplien

Claudio Puviani