Abraxas CCS Home CCS Table of Contents CCS
CodeCheck Rule-Files for CCS - C++ ccs-test.ccp
// 15) Use const proactively.
// bad 15
// ok 15
CCS - CC++ Function Definition: f15
// 16) Avoid macros.
// 17) Avoid magic numbers.
// bad 17, magic number
// bad 17, magic
// good 17
// good 17.
// good 17
// 18) Declare variables as locally as possible.
The theory here is two problems, NOT only the decl, but the usage, the usage of the global
is as important, if NOT more important than the declaration, .e.g. if you mission is to fix code.
// bad 18, declaration
CCS - CC++ Function Definition: F18
// good 18
// bad 18, using a local
// good 18
// 19) Always initialize variables.
CCS - CC++ Function Definition: f19
// bad 19 declare
// trigger on the case of a declare without an init
// good 19
// bad 19 usage
// trigger on the case of a non-init being used.
// good 19
// 20) Avoid long functions. Avoid deep nesting.
CCS - CC++ Function Definition: F20
// bad 20, > miller number of decisions
// bad 20, if function > one page of code
// bad 20, deep nesting [ USER SELECTABLE - DEFAULT 3 ]
21) Avoid initialization dependencies across compilation units.
// bad 21, global declare in a namespace
// 22) Minimize definitional dependencies. Avoid cyclic dependencies.
// fwd decl Child
// class Child;
class Parent {
// bad 22, Parent depends on Child
Child * child;
// define Parent in 22p.h
// bad 22, Child depends on Parent, but parent is in different module
// trigger on member decl parent, as base-name Parent was defined out-of-module
// 23) Make header files self-sufficient.
// 24) Always write internal #include guards. Never write external #include guards.
// verify that 24.h has guard
// good 24, 24.h has correct guard
// bad 24
// 24) Always write internal #include guards. Never write external #include guards.
//25) Take parameters appropriately by value, (smart) pointer, or reference.
// bad 25, never pass a user type by value
CCS - CC++ Function Definition: f25a
CCS - CC++ Function Definition: f25b
CCS - CC++ Function Definition: f25c
26) Preserve natural semantics for overloaded operators.
// bad 26, dangerous to overload primitive operators in local project code
27) Prefer the canonical forms of arithmetic and assignment operators.
If the "L@R" case is overloaded, then the "L@=R" MUST be overloaded, and L@R MUST
be defined in terms of L@=R
// bad 27, the minus is intentionally missing the -= case
// good 27
CCS - CC++ Function Definition: operator+=
CCS - CC++ Function Definition: operator+
// bad 27, no operator-=
CCS - CC++ Function Definition: operator-
28) Prefer the canonical form of ++ and --. Prefer calling the prefix forms.
// if your class builds ++foo, then handle the foo++ case.
// bad 28, the minus is intentionally missing postfix case
// good 28
T& operator++ ( ) {} // ++foo
const T operator++ ( int ) {} // foo++
// bad 28, no postfix case
T& operator-- ( ) {} // prefix imp
main() {
T i;
++i;
i.operator++(); // prefix actuality
i++;
i.operator++(0); // postfix actuality
// 30) Avoid overloading &&, ||, or , (comma).
// bad 30
// ok 30
// 31) Don't write code that depends on the order of evaluation of function arguments.
// bad 31, don't return side-effect
CCS - CC++ Function Definition: inc31
CCS - CC++ Function Definition: f31
// bad 31, don't call with multiple side-effect on same object
// 33) Prefer minimal classes to monolithic classes.
the theory here is that if any of the five major components of a class are greater than
the miller-number [ 7 ], then the class is too big. the definition of 'monolithic class' is
user selectable.
34) Prefer composition to inheritance.
//private:
CCS - CC++ Function Definition: f34
// 36) Prefer providing abstract interfaces.
// if a class doesn't have a base, then verify that pure abstraction is used
// bad abstract class without pure interface
37) Public inheritance is substitutability. Inherit, not to reuse, but to be reused.
// verify that inheritance specializes the usage
CCS - CC++ Function Definition: C37
// 38) Practice safe overriding.
39) Consider making virtual functions nonpublic, and public functions nonvirtual.
40) Avoid providing implicit conversions.
// bad 40, implicit type conversion associatd with this class
41) Make data members private, except in behaviorless aggregates (C-stylestructs).
// The essence here is that member's that are derived from class must be private
// 42) Don't give away your internals.
CCS - CC++ Function Definition: f42
// here the public function f42 is 'giving away' private data
// 42) Don't give away your internals.
CCS - CC++ Function Definition: f42
// here the public function f42 is 'giving away' private data
// 43) Pimpl judiciously.
CCS - CC++ Function Definition: operator=
// boost example
namespace boost {
template class shared_ptr ;
struct Foo;
typedef boost::shared_ptr FooPtr;
struct FooPtrOps
bool operator()( const FooPtr & a, const FooPtr & b )
void operator()( const FooPtr & a )
// 44) Prefer writing nonmember nonfriend functions.
// 45) Always provide new and delete together.
// verify that the new & deletes balance
// bad 45, for C45B the delete is missing
// static void * operator delete(void*, size_t);
// 46) If you provide any class-specific new, provide all of the standard forms (plain, in-place, and nothrow).
// 58) Keep types and functions in separate namespaces unless they're specifically intended to work together.
namespace std {
template class vector {
CCS - CC++ Function Definition: operator+
CCS - CC++ Function Definition: f58
// 59. Namespaces and Modules. Don't write namespace usings in a header file or before an #include.
// 60) Avoid allocating and deallocating memory in different modules.
// two files 60.cpp that defines and allocates object, and 60a.cpp that de-allocates
CCS - CC++ Function Definition: f60
// 60) Avoid allocating and deallocating memory in different modules.
// two files 60.cpp that defines and allocates object, and 60a.cpp that de-allocates
// C60 *c60 = new C60; // allocate c60 in 60.cpp
CCS - CC++ Function Definition: f60a
// bad c60 not defined in this module
// 61) Don't define entities with linkage in a header file.
CCS - CC++ Function Definition: f61
// 62) Don't allow exceptions to propagate across module boundaries.
CCS - CC++ Function Definition: main
// 62) Don't allow exceptions to propagate across module boundaries.
CCS - CC++ Function Definition: f62a
// bad this throw is based on object outside of this module
// 63) Use sufficiently portable types in a module's interface.
//#include // load namespace std;
//using namespace std; // here its explicit
// for simplictiy create our own silly little namespace std;
// good portable, stdlib param and return
// good portable low level types
// not portable, two warnings, function and parameter are abstract and not stdlib
// 65) Customize intentionally and explicitly.
CCS - CC++ Function Definition: f65
// 95. Type Safety. - Don't use C-style casts.
// bad, don't use old style c casting
96) Don't memcpy or memcmp non-PODs.
CCS - CC++ Function Definition: f96
// bad 96, don't use memcpy
// bad 96, don't use memcmp
// 97) Don't use unions to reinterpret representation.
CCS - CC++ Function Definition: f97
// bad 97
// bad 97
98) Don't use varargs (ellipsis).
// bad 98, ...
99) Don't use invalid objects. Don't use unsafe functions.
CCS - CC++ Function Definition: m99
// bad 99, don't use unsafe functions
Abraxas/CCS Home Table of Contents CCS