My suggestions:

 * When it is appropriate to use a child class with virtual functions,
   the virtual functions should all be declared as protected in the
   parent class.

At first reading, I thought you meant "all virtual functions should be
protected", but I think you meant "if a child ADDS a virtual function
that the parent doesn't have, ...", but in that case I don't see why the
parent needs a declaration at all.  This should be clarified.

 * Namespaces

In general, I don't like namespaces, unless you're defining a package.
Class names create their own name spaces, globals should be global, etc.
Saying "everything should be in a namespace" is IMHO an inappropriate
restriction.  Indicate where namespaces are appropriate, leave it at
that.

 * All data members should be private.
 * All data members should have names which end with an underscore.

This makes all structures illegal.  I'd remove the first "All" and
replace the second with "Private":

 * Data members should be private.
 * Private data members should have names which end with an underscore.


 * When a method refers to a non-static data member, it should always
   qualify the reference with this->.

I'm very opposed to this.  To me, it makes the code less readable
because it lets the author write code that's hard to understand at a
larger scope.  I would forbid explicit references to "this" except to
pass it unadorned as a parameter to some other function.  If it's not
clear where method call data comes from, write clearer code!

If you're implementing a class, it should be clear you're implementing a
class, and implied that data/methods come from the class unless
specified otherwise (which you'd have to do anyway, like foo->reg_p()).
If it's not clear, you've not properly encapsulated the class and you
need to redesign it so it *is* properly contained and easy to
understand.

If you're not implementing a class, you'd never use "this" anyway.

DJ never refers to himself in the third person, I don't see why his code
should.


 * At least for now we will continue to use printf style I/O rather than
   <iostream> style I/O

THANK YOU!

 * use of existing templates, e.g., from the standard library, is fine

I'd prefer avoiding pulling in STL stuff at first.  I find STL to be
quite a "culture shock" relative to C.  When used I'd limit it to one
STL object at a time - avoid containers of lists of vectors of strings,
etc.

Additions:

* Local variables should be declared where they're first used, if their
  use is contiguous and localized.  If they're ubiquitous (like a return
  value temporary) or reused later (like "i" for for-loop iterators),
  declare them at the beginning of the function.

* Use C-style comments for multi-line comments, and C++-style comments
  for single-line comments.

Reply via email to