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

[jeffc]

"Pete Vidler" <pv*****@mailbl ocks.com> wrote in message
news:OV******** ****@newsfe1-gui.server.ntli .net...

A suggestion. Functions could easily be longer once you add blank lines and comments. Functions that are pretty straightforward but long, say because they have to read in a lot of input arguments, are fine, it seems to me. As soon as you start to process input arguments and do stuff, that's when the long function should raise a bell.

A related concept is that functions should have few input arguments.

I usually adhere to this one because I find that I make fewer mistakes
if the entire method is immediately available. I'm not sure how this
relates to the number of arguments, but I'll accept that as a suggestion.

Worry about cohesion rather than number of lines. If you worry too much
about number of lines, then you'll start breaking down every 2 lines into
function, and that can make things *less* readable ultimately.

[Siemel Naran]

"jeffc" <no****@nowhere .com> wrote in message
news:40******** @news1.prserv.n et...

"Siemel Naran" <Si*********@RE MOVE.att.net> wrote in message

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

What?

Makes sense to me, and I wholeheartedly agree. Nothing worse than
unnecessary dependencies in header files.

You mean like header A.h fails to include B.h though it depends on entities
from B.h. Then the user who includes A.h has to include B.h first then A.h.
Is this what you mean? If so, definitely this is a good rule.

In fact, my cpp files always include the h file as the first non-comment
line. But in windows they have this stdafx.h if you use pre-compiled
headers, and so you shouldn't by accident include B.h in this file.

[Steven T. Hatton]

Pete Vidler wrote:

I am not patting myself on the back. I do not believe it will be obvious
to me. It's just that the book has some /very/ mixed reviews on the
internet, so I need some solid reassurance that it covers the kind of
guidelines that I mentioned earlier before I go out and buy it.

-- Pete

I got to #3, and so far, I'm finding these worth considering. I suggest
reading with your eyes open. #3 threw me for a loop at first.

The Top 20 C++ Tips of All Time
http://www.devx.com/cplus/Article/16328/0/page/1
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Steven T. Hatton]

Steven T. Hatton wrote:

Pete Vidler wrote:

I am not patting myself on the back. I do not believe it will be obvious
to me. It's just that the book has some /very/ mixed reviews on the
internet, so I need some solid reassurance that it covers the kind of
guidelines that I mentioned earlier before I go out and buy it.

-- Pete I got to #3, and so far, I'm finding these worth considering. I suggest
reading with your eyes open. #3 threw me for a loop at first.

Doh! #2 is the one that tripped me up.
The Top 20 C++ Tips of All Time
http://www.devx.com/cplus/Article/16328/0/page/1

Can I trust #4? I believe I can by virtue of this:
http://www.itga.com.au/~gnb/wp/cd2/
3.6.2 Initialization of non-local objects [basic.start.ini t]

1 The storage for objects with static storage duration
(_basic.stc.sta tic_) shall be zero-initialized (_dcl.init_) before any
other initialization takes place. Objects of POD types
(_basic.types_) with static storage duration initialized with constant
expressions (_expr.const_) shall be initialized before any dynamic
initialization takes place. Objects of namespace scope with static
storage duration defined in the same translation unit and dynamically
initialized shall be initialized in the order in which their defini-
tion appears in the translation unit. [Note: _dcl.init.aggr_
describes the order in which aggregate members are initialized. The
initialization of local static objects is described in _stmt.dcl_. ]

But I'm not sure if there are any subtelties I need to be aware of.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Christopher Benson-Manica]

Siemel Naran <Si*********@re move.att.net> spoke thus:

In fact, my cpp files always include the h file as the first non-comment
line. But in windows they have this stdafx.h if you use pre-compiled
headers, and so you shouldn't by accident include B.h in this file.

If one writes header files correctly, including header files
accidently causes very minor effects at worst.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.