Cameron said:
I was wondering how good this page of coding standards
(
http://www.doc.ic.ac.uk/lab/cplus/c++.rules/) is.
Ah, someone got paid for a week to write a Web site instead of source
code...
It contains a 'void main', which reveals cluelessness.
"Do not use unspecified function arguments (ellipsis notation)." is kosher.
"Optimize code only if you /know/ that you have a performance problem" is
advice too many /still/ need. "Compile with all warnings turned on" is
correct - if you can turn a few off individually. "The public, protected,
and private sections of a class are to be declared in that order" is okay,
but could mention classes should be so short the rule's not needed.
"No member functions are to be defined within the class definition" is a
strategy to deal with inline. Either inline everything or nothing, then only
use performance tuning and profiling to detect which thing's inline status
needs changing. But the rule "put classes in .cpp file without overwhelming
reasons to put them in .h files" could have worked better. That's a
specialization of "give identifiers the narrowest scope possible."
The section for Variables is harmless, except it says "Variables are to be
declared with the smallest possible scope.". This rule should apply to any
identifier, not just variables. These rules are against C style code that
declares billions of variables at the top of a long method, and then doesn't
assign them all.
It doesn't seem to mention automated unit tests. The rule "Never specify
public or protected member data in a class" is a little bit LESS important
than "test every line, duh!"
The rule "Never specify public or protected member data in a class" really
means "don't make primitive things globally accessible".
The rule "The identifier of every globally visible class, enumeration type,
type definition, function, constant, and variable in a class library is to
begin with a prefix that is /unique/ for the library" predates namespaces. I
t's the "Registered Package Prefix" system from /Large Scale C++ Software
Design/.
The guidelines mix esthetic and technical recommendations annoyingly, to
follow the general outline.
The section for "Pointers and References" doesn't mention, technically, to
prefer references without a reason to point.
The recommendation "An include file should not contain more than one class
definition" is stupid. Header files should contain enough stuff to solve one
problem. A few small classes colluding to solve one problem are generally
more comprehensible than one big one, or many header files that always go
together. The verbiage could have saved itself by recommending one
uber-class nest all its minion classes inside itself, but instead the
verbiage just says "no exceptions".
The stuff about comments is essentially "code deodorant". One should clean
up stinky code, instead of deodorize it.
"Never use explicit UNIX path names" is incorrect. / slash works fine on
Win32.
The stuff about variable naming should say "names should reveal intent, and
be pronouncable". The (literally) global variable "WWW" fails both those
checks.
'A class which uses "new" to allocate instances managed by the class, [i.e.
instances bound to member variables of pointer or reference type that are
deallocated by the object.] must define a copy constructor. ' The better
advice here is to either don't call 'new', or to write very small classes
that call it, then use these classes as members.
This advice predates STL, and contains much /Effective C++/ stuff. A C-minus
effort like this reveals Scott Meyers's brilliance, narrowing these rules
down to their absolute cores.
The rules about switch statements could mention replacing conditionals on
typecodes with polymorphism. That's the heart of the Object Oriented
paradigm, and these rules are generally mired in "C style C++" land.
