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
Jul 22 '05
64  3370 
"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
"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?
Good information is never out of date. Knuth's "Art of Computer Programming"
series was first published in 1968 and anyone would get shot for calling it
out of date. A discriminating reader can easily filter out what's still
relevant and what isn't. Those who can't are probably not ready to read the
book yet.
I've also heard that he has some strange guidelines like
not using namespaces?
EVERY book that proposes guidelines has strange guidelines. Or at least, we
perceive them as being strange because the author comes from a different
background. The thing to remember is that guidelines are NOT rules and
should be followed only if they make sense in a given context. Taking John's
admonition against using namespaces out of context is less than meaningless.
What he actually suggested, which anyone who actually read the book would
know, is to wait until namespace support was more stable and universal
before using it. At the time the book was written, there were quite a few
compilers that didn't support namespaces or that supported them incorrectly.
The truth is that whether or not one appreciates John's style or agrees with
every detail, anyone who hasn't read the book is a step behind those who
have with regard to physical design.
Claudio Puviani
"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?
Good information is never out of date. Knuth's "Art of Computer Programming"
series was first published in 1968 and anyone would get shot for calling it
out of date. A discriminating reader can easily filter out what's still
relevant and what isn't. Those who can't are probably not ready to read the
book yet.
I've also heard that he has some strange guidelines like
not using namespaces?
EVERY book that proposes guidelines has strange guidelines. Or at least, we
perceive them as being strange because the author comes from a different
background. The thing to remember is that guidelines are NOT rules and
should be followed only if they make sense in a given context. Taking John's
admonition against using namespaces out of context is less than meaningless.
What he actually suggested, which anyone who actually read the book would
know, is to wait until namespace support was more stable and universal
before using it. At the time the book was written, there were quite a few
compilers that didn't support namespaces or that supported them incorrectly.
The truth is that whether or not one appreciates John's style or agrees with
every detail, anyone who hasn't read the book is a step behind those who
have with regard to physical design.
Claudio Puviani
"Pete Vidler" <pv*****@mailbl ocks.com> wrote in message
news:ShTdc.309$ sp4.218@newsfe1- 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):
We should have guidelines and suggestions. Suggestions are weaker than
guidelines.
- Functions should fit on one screen, from various sources.
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.
- Non-leaf classes should be abstract (have pure virtual methods), from
More Effective C++, Item 33.
A suggestion. Sometimes we want a reasonable default behavior which clients
can then override. Requring the above as a guideline imposes too much
design burden on the project and could cause it to run out of budget.
- 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.
They should be private or protected. Often, a virtual function will call
the same function in the base class and do some additional processing, as
for example a virtual equal function. I generally call the private virtual
functions myaction, and the protected ones doaction.
- Header files should be self contained, from various sources.
What?
- Destructors for base classes should be either virtual or protected.
No. Classes meant to not be derived from may have public non-virtual
destructors, such as std::vector.
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?
There are lots of others.
"Pete Vidler" <pv*****@mailbl ocks.com> wrote in message
news:ShTdc.309$ sp4.218@newsfe1- 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):
We should have guidelines and suggestions. Suggestions are weaker than
guidelines.
- Functions should fit on one screen, from various sources.
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.
- Non-leaf classes should be abstract (have pure virtual methods), from
More Effective C++, Item 33.
A suggestion. Sometimes we want a reasonable default behavior which clients
can then override. Requring the above as a guideline imposes too much
design burden on the project and could cause it to run out of budget.
- 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.
They should be private or protected. Often, a virtual function will call
the same function in the base class and do some additional processing, as
for example a virtual equal function. I generally call the private virtual
functions myaction, and the protected ones doaction.
- Header files should be self contained, from various sources.
What?
- Destructors for base classes should be either virtual or protected.
No. Classes meant to not be derived from may have public non-virtual
destructors, such as std::vector.
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?
There are lots of others.
Siemel Naran wrote:
[snip] 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):
We should have guidelines and suggestions. Suggestions are weaker than
guidelines.
I see no difference. I am just as free to ignore either. The purpose of
my post was to find out what various people (or websites, books, etc)
might have to say about what they consider to be "good" design.
- Functions should fit on one screen, from various sources.
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.
- Non-leaf classes should be abstract (have pure virtual methods), from
More Effective C++, Item 33.
A suggestion. Sometimes we want a reasonable default behavior which clients
can then override. Requring the above as a guideline imposes too much
design burden on the project and could cause it to run out of budget.
You can have pure virtual methods with an implementation. Note that
abstract in this case means simply that the class has >=1 pure virtual
method, not that they are all pure virtual (my interpretation of that
source).
Having tried this in a recent project, it really isn't that much of a
burden (most of my classes were close anyway).
- 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.
They should be private or protected. Often, a virtual function will call
the same function in the base class and do some additional processing, as
for example a virtual equal function. I generally call the private virtual
functions myaction, and the protected ones doaction.
Aside from the naming that is exactly what I posted? Except that I'm not
too sure about having a virtual "equal function".
- Header files should be self contained, from various sources.
What?
I posted more info on this elsewhere in the thread. Basically I just
meant that you should be able to include the header at the very top of
your source file and not get errors.
- Destructors for base classes should be either virtual or protected.
No. Classes meant to not be derived from may have public non-virtual
destructors, such as std::vector.
Umm.. since when is std::vector a base class? A base class is one that
has been (or is intended to be) derived from (IMO).
[snip] There are lots of others.
That doesn't help. The entire purpose of my post was to get people to
post some (or post links, etc).
-- Pete
Siemel Naran wrote:
[snip] 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):
We should have guidelines and suggestions. Suggestions are weaker than
guidelines.
I see no difference. I am just as free to ignore either. The purpose of
my post was to find out what various people (or websites, books, etc)
might have to say about what they consider to be "good" design.
- Functions should fit on one screen, from various sources.
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.
- Non-leaf classes should be abstract (have pure virtual methods), from
More Effective C++, Item 33.
A suggestion. Sometimes we want a reasonable default behavior which clients
can then override. Requring the above as a guideline imposes too much
design burden on the project and could cause it to run out of budget.
You can have pure virtual methods with an implementation. Note that
abstract in this case means simply that the class has >=1 pure virtual
method, not that they are all pure virtual (my interpretation of that
source).
Having tried this in a recent project, it really isn't that much of a
burden (most of my classes were close anyway).
- 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.
They should be private or protected. Often, a virtual function will call
the same function in the base class and do some additional processing, as
for example a virtual equal function. I generally call the private virtual
functions myaction, and the protected ones doaction.
Aside from the naming that is exactly what I posted? Except that I'm not
too sure about having a virtual "equal function".
- Header files should be self contained, from various sources.
What?
I posted more info on this elsewhere in the thread. Basically I just
meant that you should be able to include the header at the very top of
your source file and not get errors.
- Destructors for base classes should be either virtual or protected.
No. Classes meant to not be derived from may have public non-virtual
destructors, such as std::vector.
Umm.. since when is std::vector a base class? A base class is one that
has been (or is intended to be) derived from (IMO).
[snip] There are lots of others.
That doesn't help. The entire purpose of my post was to get people to
post some (or post links, etc).
-- Pete
Claudio Puviani wrote:
[snip] It has rudimentary design guidelines as well. The formatting section is just
a few pages, and the least interesting at that.
But how rudimentary? I can't possibly buy a book on the off-chance it
might contain what I need (I couldn't afford it). I can't find any
actual reviews of the book, and the only info in the summary suggets the
book is about formatting/naming conventions (useless to me).
Here's a list of books I posted once before that would give you what you
need:
Cool, thanks. I have read most of these, but there are one or two on
that list I haven't seen before.
-- Pete
Claudio Puviani wrote:
[snip] It has rudimentary design guidelines as well. The formatting section is just
a few pages, and the least interesting at that.
But how rudimentary? I can't possibly buy a book on the off-chance it
might contain what I need (I couldn't afford it). I can't find any
actual reviews of the book, and the only info in the summary suggets the
book is about formatting/naming conventions (useless to me).
Here's a list of books I posted once before that would give you what you
need:
Cool, thanks. I have read most of these, but there are one or two on
that list I haven't seen before.
-- Pete
Claudio Puviani wrote:
[snip] I've heard of this one, but isn't it seriously out of date?
Good information is never out of date. Knuth's "Art of Computer Programming"
series was first published in 1968 and anyone would get shot for calling it
out of date. A discriminating reader can easily filter out what's still
relevant and what isn't. Those who can't are probably not ready to read the
book yet.
Right, but if it almost pre-dates namespaces there is going to be a lot
missing from it -- am I right? Templates and such?
Knuth's book is somewhat different, the concepts it addresses are not
based on a language that has changed a great deal over time. It isn't
even based on a real language at all (unless you count a few
implementations by enthusiasts).
I've also heard that he has some strange guidelines like
not using namespaces?
EVERY book that proposes guidelines has strange guidelines. Or at least, we
perceive them as being strange because the author comes from a different
background. The thing to remember is that guidelines are NOT rules and
should be followed only if they make sense in a given context.
[snip]
I have to disagree. I have read many guideline type books (the
"Effective" and "Exceptiona l" books to name five) that I have had no
disagreements with at all. I don't believe I come from the same
background as the authors.
The truth is that whether or not one appreciates John's style or agrees with
every detail, anyone who hasn't read the book is a step behind those who
have with regard to physical design.
[snip]
That cannot possibly be true. If we haven't read the book we might still
know everything it contains (through other sources) and not realise it.
And for all I know, if I do read it much of its contents might be
obvious to me.
-- Pete This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: beliavsky |
last post by:
Is there a more recent set of Python style guidelines than PEP 8,
"Style Guide for Python Code", by van Rossum and Warsaw, at
http://www.python.org/peps/pep-0008.html , which is dated July 5,
2001?
|
by: stevehayter |
last post by:
Wonder if anyone can help me solve this problem!
I have a 3x3 table which i'm using to create a table with a rounded
edge using images in the top left, top right, bottom left, and bottom
right cells and lines in the top/left/right and bottom cells (sounds
odd, you'll see what i mean when you see the site). It works fine,
except the top and bottom rows are a lot bigger than i've specified
when they should be flush with the centre cell as...
|
by: Pete Vidler |
last post by:
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.
|
by: E. Robert Tisdale |
last post by:
C++ Programming Style Guidelines
http://geosoft.no/development/cppstyle.html
I think that these guidelines are almost *all* wrong.
For example:
11. Private class variables should have underscore suffix.
class SomeClass {
private:
|
by: jamilur_rahman |
last post by:
What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?
style A:
....
....
int a = 1;
if(0==a)
{
| | |
by: John Salerno |
last post by:
Does Microsoft have any naming guidelines for variables? I've been
reading their guidelines for just about every other type (methods,
parameters, properties, etc.) but nothing about variables. Are variables
treated the same as parameters (i.e., camel case)?
I notice that Hungarian notation is being done away with.
Also, is it good practice to use an underscore to begin the name of a
field? I've seen that, and it seems like a good idea,...
|
by: Laurent Bugnion [MVP] |
last post by:
Hi group,
In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.
http://www.galasoft-lb.ch/myjavascript/Siemens_SBT_JavaScript_Coding_Guidelines.pdf
Please note the following:
|
by: mrashidsaleem |
last post by:
Can anyone guide me what is wrong with the naming conventions
suggested below? I know that this is not recommended by many
(including Microsoft) but I need to know what exactly is the rationale
behind going for a different convention in .NET. The recommendations
do make sense (to me, at least but I may be wrong and would like
someone to correct me).
Scope Prefixes
Member Variable Prefix: Most of the people still use (and like the
idea...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
| | |
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
