Code Analysis

Language:  C, C++, C# and Java

Rationale:  Reproducing source code on devices that are limited to 80 columns of text can cause the truncation of the line or wrap the line.  Wrapped source lines are difficult to read, thus creating weaker peer reviews of the source code.

Rationale:  Long function names may be a portability issue especially when code has to be cross compiled onto embedded platforms.  This difficultly is typically seen with older hardware and operating systems.

Rationale:  Ellipsis create a variable argument list.  This type of design is found in C and C++.  It essentially breaks the type strict nature of C++ and should be avoided.

Language:  C, C++, C# and Java

Rationale:  An assignment within an "if" condition is likely a typographical error giving rise to a logic defect.  However, some programmers place compound statements into the "if" condition making the code difficult to read.

Language:  C, C++, C# and Java

Rationale:  An assignment within a "while" condition is likely a typographical error giving rise to a logic defect.  However, some programmers place compound statements into the "while" condition making the code difficult to read.

Rationale:  The pre-decrement of a variable occurs before the remainder of the processing in the statement.  This can be difficult to comprehend or anticipate.  There are documented cases where the mathematical results vary between the result of macros when different code preprocessors expand the macros into a normal form.  Remember, there is no standard for the preprocessor, just the language.

Language: C and C++ for preprocessor anomalies and C, C++, C# and Java for understandability of the code.

Rationale:  The pre-increment of a variable occurs before the remainder of the processing in the statement.  This can be difficult to comprehend or anticipate.  There are documented cases where the mathematical results vary between the result of macros when different code preprocessors expand the macros into a normal form.  

Language:  C and C++

Rationale:  Using realloc can lead to latent memory leaks within your C or C++ code.  The call to realloc reassigns the pointer to the same memory address using a larger or smaller space.  However if realloc fails, a NULL pointer is returned.  No "free" was performed on the pointer so if you don't retain the pointer before the realloc call, a latent memory leak could occur.

Language:  C and C++

Rationale:  The use of "goto" creates spaghetti code.  A "goto" can jump anywhere to the destination label.  This type of design breaks the "one in - one out" ideal of a function creating code which can be impossible to debug or maintain.

Language:  C affecting ANSI C and C++

Rationale:  Older C code can be written in a style that does not use function prototypes of the function argument types.  This code will not compile on ANSI C and C++ compilers because of this type of weakness.  Identifying this condition can help assess whether code can be ported to a newer version of the language. 

Language:  C and C++

Rationale:  This type of error is always caught by the compiler as a syntax error.  However, a compiler can be told to ignore source code by using preprocessor directives like #if ... #endif.  This is a way to "comment" out large blocks of code.  However, the code still looks like operational code to the maintainer as it is not a comment.  Many hours can be wasted working on dead code.  This quality notice serves to warn you of this dead code that should be removed or converted to actual comment form.

Language:  C and C++

Rationale:  This type of error is always caught by the compiler as a syntax error.  However, a compiler can be told to ignore source code by using preprocessor directives like #if ... #endif.  This is a way to "comment" out large blocks of code.  However, the code still looks like operational code to the maintainer as it is not a comment.  Many hours can be wasted working on dead code.  This quality notice serves to warn you of this dead code that should be removed or converted to actual comment form.

Language:  C, C++, C# and Java

Rationale:  A "switch" statement must always have a default condition or this logic construct is non-deterministic.  Generally the default condition should warn the user of an anomalous condition which was not anticipated by the programmer by the case clauses of the switch.

Language:  C, C++, C# and Java

Rationale:  Many tools, including RSM, watch the use of "case" and "break" to insure that there is not an inadvertent fall through to the next case statement.  RSM requires the programmer to explicitly indicate in the source code via a "fall through" comment that the case was designed to fall through to the next statement.
     case 'a':  // fall through
     case 'b':
     { ... }

Language:  C++

Rationale:  Friend classes create a large aggregation of classes all acting like a huge meta class.  Friend classes can freely share all private data thus breaking the principle of data hiding.  This type of design is never recommended.  The use of friend classes indicates a flaw in the system design.

Language:  C, C++, C# and Java

Rational:  Source code must be easily read.  A low percentage of white space indicates that the source code is crammed together thus compromising the readability of the code.  Typically white space less than 10 percent is considered crammed  code. 

Language:  C, C++, C# and Java

Rationale:  A programmer must supply sufficient comments to enable the understandability of the source code.  Typically a comment percentage less than 10 percent is considered insufficient.  However, the content quality of the comment is just as important as the quantity of the comments.  For this reason you could use the -E option to extract all the comments from a file.  The reviewer should be able to read the comments and extract the story of the code.

Language:  C, C++, C# and Java

Rationale:  An extremely large function is very difficult to maintain and understand.  When a function exceeds 200 eLOC (effective lines of code), it typically indicates that the function could be broken down into several functions.  Small modules are desirable for modular composability.

Language:  C, C++, C# and Java

Rationale:  Source code must be easily read.  A low percentage of white space indicates that the source code is crammed together thus compromising the readability of the code.  Typically white space less than 10 percent is considered crammed  code. 

Language:  C, C++, C# and Java

Rationale:  A programmer must supply sufficient comments to enable the understandability of the source code.  Typically a comment percentage less than 10 percent is considered insufficient.  However, the content quality of the comment is just as important as the quantity of the comments.  For this reason you could use the -E option to extract all the comments from a file.  The reviewer should be able to read the comments and extract the story of the code.

Language:  Not Applicable

Language:  C, C++, C# and Java

Rationale:  Logical blocks should be bound with scope.  This clearly marks the boundaries of scope for the logical blocks.  Many times, code may be added to non-scoped logic blocks thus pushing other lines of code from the active region of the logical construct giving rise to a logic defect.

Language:  C and C++

Rationale:  The ? operator creates the code equivalent of an "if" then "else" construct.  However the resultant source is far less readable.

Language:  C and C++

Rationale:  In C source code it is possible to find variable names like "class".  This word is a key word in C++ and would prevent this C code from being ported to the C++ language.

Language:  C and C++

Rationale:  A *.h file can be either a C or C++ source file.  If a *.h file is assumed to be from either language, then RSM will not emit C keyword notices in *.h file, only for *.c files.

Language:  C and C++

Rationale:  A "void *" is a type-less pointer.  ANSI C and C++ strives to be type strict.  In C++ a "void *" breaks the type strict nature of the language which can give rise to anomalous run-time defects.

Language:  C, C++, C# and Java

Rationale:  A well constructed function has one entry point and one exit point.  Functions with multiple return points are difficult to debug and maintain.

Language:  C, C++, C# and Java

Rationale:  Cyclomatic complexity is an indicator for the number of logical branches within a function.  A high degree of V(g), greater than 10 or 20, indicates that the function could be broken down into a more modular design of smaller functions.

Language:  C, C++, C# and Java

Rationale:  A high number of input parameters to a function indicates poor modular design.  Data should be grouped into representative data types.  Functions should be specific to one purpose.

Language:  C, C++, C# and Java

Rationale:  Tab characters within source code create documents that are print and display device dependent.  The document may look correct on the screen but it may become unreadable when printed.

Language:  C, C++, C# and Java

Rationale:  A programmer must supply sufficient comments to enable the understandability of the source code.  Typically a comment percentage less than 10 percent is considered insufficient.

Language:  C++

Rationale:  The construct "using" for a namespace creates large virtual namespaces where name collisions become highly probable.  Identifiers become part of this large virtual namespace and it is not evident where they belong.  "Using" destroys the concept of the namespace.

Language:  C++, C# and Java

Rationale:  Defining a "class" within a function is poor design.  Classes should be defined atomically or within the classes for which they are solely used..

Language:  C++

Rationale:  When a class contains a pointer and the class allocates memory for that pointer, the class must contain a copy constructor and a destructor that correctly manages the dynamic memory.  Identifying which classes contain pointers can improve the peer review of the source code.

Language:  C++, C# and Java

Rational:  Public data breaks the data encapsulation of a class.  Public data may be applicable to data container classes which become private data objects of other classes.  However, primary classes in a design should never contain unprotected data.

Language:  C++, C# and Java

Rationale:  Protected data is directly accessible down the inheritance chain.  If your standards prohibit such design, RSM will identify where this construct exists.

Language: C++

Rationale:  Classes that contain virtual methods form a vtable for the management of the virtual methods.  Polymorphism requires that a virtual destructor exist or proper cleanup of the object is not performed when "delete" is called on the pointer to the polymorphic object.

Language:  C++, C# and Java

Rationale:  Exception handling is a natural part of the Java language but in C++ it is an added feature.  Exception handling creates code that jumps around to the catch blocks of the exceptions.  It is our experience that code with developer imposed exception handling is very difficult to implement and maintain.  The rule of thumb is that exception handling should be part of the design not an after thought in the implementation.

Language:  C++, C# and Java

Rationale:  Classes with an extremely large number of methods are indicators of poor modularity.  A module and or data type should be of a singular purpose.

Rationale:  As the inheritance tree grows deeper and deeper, maintenance of the classes becomes very difficult.  A deep inheritance tree can indicate that the lower level IS-A classes could be parameterized in a shallower class tree.

Language:  C++, C# and Java

Rationale:  A great number of child classes can indicate that generalization of the class tree was not performed or that the differentiation between the children is so slight that a parameterized class may be more efficient.

Rationale:  The use of multiple inheritance must be design driven.  Implementing ad-hoc multiple inheritance can cause spurious behavior from the objects that derive behaviors from the two base classes.

Language:  C, C++, C# and Java

Rationale:  The use of 'continue' in logical structures causes a disruption in the linear flow of the logic.  This style of  programming can make maintenance and readability difficult.

Rationale:  The use the 'break' statement outside a 'switch' block disrupts the linear logic flow of a function.  This style of programming can make code maintenance and readability difficult.