What’s Inside Your Source Code?

Knowing what is inside your source code is the first step in assessing the quality of the software product. Knowing the quantity of work performed in generating the source code is the first step in determining the productivity of your software team. Resource Standard Metrics measures the quantity and quality of your source code by measuring the language attributes and lines of code, LOC.  RSM reports are available in text, html and csv formats (RSM Options and Report).  Some of the metrics RSM calculates are explained at the following link (Metrics Narration).

Metrics and Analysis

Function Metrics Example

Per Function

All Functions

      Total, Average, Maximum and Minimums

Class Metrics Example

Per Class

All Classes

     Total, Average, Maximum and Minimum

Namespace or Package Metrics Example

Per Namespace

All Namespace/Packages

     Total, Average, Maximum and Minimum

File Metrics

Project Metrics

divider.jpg (1531 bytes)

(Last Update: June 12, 2001 )
Copyright 2001, M Squared Technologies

--------------9A401C9600485937F05072E9 Content-Type: text/html; charset=us-ascii; name="rsm_analysis.htm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rsm_analysis.htm" RSM Quality Analysis

RSM
Source Code Analysis

RSM checks source code for standard coding practices. C, C++ and Java allow certain constructs in the language that are problematic for the reliability and maintenance of software. The coding practices included in source code analysis are configurable by the end user. The Configuration File will facilitate this customization.

The following internal source code quality issues are common problems found in C, C++ and Java. These issues have been derived from industry standard coding practices, portability guidelines and common errors performed in programming. Enforcement of the issues will produce a more easily read, understood, maintained and reliable software product.

Quality Notices Detected in the Source Code

Quality Notice No. 1
Emit a quality notice when the physical line length is greater than the specified number of characters.

Language:  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.

Quality Notice No. 2
Emit a quality notice when the function name length is greater than the specified number of characters.

Language: C and Possibly C++

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.

Quality Notice No. 3
Emit a quality notice when ellipsis '...' are identified within a functions parameter list thus enabling variable arguments.

Language:  C and C++

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.

Quality Notice No. 4
Emit a quality notice if there exists an assignment
operator '=' within a logical 'if' condition.

Language:  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.

Quality Notice No. 5
Emit a quality notice if there exists an assignment
operator '=' within a logical 'while' condition.

Language:  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.

Quality Notice No. 6
Emit a quality notice when a pre-decrement operator '--' is identified within the code.

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

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.

Quality Notice No. 7
Emit a quality notice when a pre-increment operator '++' is identified within the code.

Language: C and C++ for preprocessor anomalies and 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.  

Quality Notice No. 8
Emit a quality notice when the 'realloc' function
is identified within the code.

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.

Quality Notice No. 9
Emit a quality notice when the 'goto' function
is identified within the code.

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.

Quality Notice No. 10
Emit a quality notice when the Non-ANSI function prototype is identified within the code.

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. 

Quality Notice No. 11
Emit a quality notice when open and closed brackets '[ ]' are not balance within a file.

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.

Quality Notice No. 12
Emit a quality notice when open and closed parenthesis '( )' are not balance within a file.

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.

Quality Notice No. 13
Emit a quality notice when a 'switch' statement does not have a 'default' condition.

Language:  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.

Quality Notice No. 14
Emit a quality notice when these are more 'case' conditions than 'break', 'return' or 'fall through' comments.

Language:  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':
     { ... }

Quality Notice No. 15
Emit a quality notice when a friend class
is identified within the code.

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.

Quality Notice No. 16
Emit a quality notice when function white space
percentage is less than the specified minimum.

Language:  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. 

Quality Notice No. 17
Emit a quality notice when function comment
percentage is less than the specified minimum.

Language:  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.

Quality Notice No. 18
Emit a quality notice when the eLOC within a
function exceeds the specified maximum.

Language:  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.

Quality Notice No. 19
Emit a quality notice when file white space
percentage is less than the specified minimum.

Language:  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. 

Quality Notice No. 20
Emit a quality notice when file comment
percentage is less than the specified minimum.

Language:  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.

Quality Notice No. 21
Emit a quality notice when a file does not contain
the specified key string.

Language:  Not Applicable

Rationale:  Many companies require a copyright statement or similar project identifier string in every source code file.  This notice identifies which files do not contain that string.

Quality Notice No. 22
Emit a quality notice when each if, else, for
or while is not bound by scope.

Language:  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.

Quality Notice No. 23
Emit a quality notice when the '?' or the implied
if-then-else construct has been identified.

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.

Quality Notice No. 24
Emit a quality notice when an ANSI C++ keyword is identified within a *.c or a *.h file.

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.

Quality Notice No. 25
When analyzing *.h files for C++ keywords,
assume that *.h can be both C and C++.

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.

Quality Notice No. 26
Emit a quality notice when a void * is identified
within a source file.

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.

Quality Notice No. 27
Emit a quality notice when the number of function return points is greater than the specified maximum.

Language:  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.

Quality Notice No. 28
Emit a quality notice when the cyclomatic complexity of a function exceeds the specified maximum.

Language:  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.

Quality Notice No. 29
Emit a quality notice when the number of function input parameters exceeds the specified maximum.

Language:  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.

Quality Notice No. 30
Emit a quality notice when a TAB character is identified within the source code. Indentation with TAB will create editor and device dependent formatting.

Language:  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.

Quality Notice No. 31
Emit a quality notice when class comment
percentage is less than the specified minimum.

Language:  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.

Quality Notice No. 32
Emit a quality notice when 'using namespace'
has been identified in a C++ source file.

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.

Quality Notice No. 33
Emit a quality notice when a class definition
is identified within a function definition.

Language:  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..

Quality Notice No. 34
Emit a quality notice when a class definition
contains a pointer to a data item.

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.

Quality Notice No. 35
Emit a quality notice when a class definition
contains public data.

Language:  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.

Quality Notice No. 36
Emit a quality notice when a class definition
contains protected data.

Language:  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.

Quality Notice No. 37
Emit a quality notice when a base class, with virtual functions, does not contain a virtual destructor.

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.

Quality Notice No. 38
Emit a quality notice when exception handling is
present within a function.

Language:  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.

Quality Notice No. 39
Emit a quality notice when the number of class methods exceeds the specified maximum.

Language:  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.

Quality Notice No. 40
Emit a quality notice when the depth of the inheritance tree exceeds the specified maximum value. 

Language:  C++ and Java

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.

Quality Notice No. 41
Emit a quality notice when the number of direct derived classes exceeds the specified maximum value.

Language:  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.

Quality Notice No. 42
Emit a quality notice when the multiple inheritance has been identified. 

Language:  C++ and Java

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.

Quality Notice No. 43
Emit a quality notice when the key word 'continue' has been identified within the source code.

Language:  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.

Quality Notice No. 44
Emit a quality notice when the keyword 'break' is used outside a 'switch' block. 

Language:  C++ and Java

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.

 

divider.jpg (1531 bytes)

(Last Update: June 12, 2001 )
Copyright 2001, M Squared Technologies

--------------9A401C9600485937F05072E9 Content-Type: text/html; charset=us-ascii; name="option_menu.htm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="option_menu.htm" Runtime Options
Runtime Options
# Cross Reference
A CSV File Output
a Memory Allocation
b Benchmarks Timing
C Comment Document
c Complexity
D De-Character Mode
d Deterministic Mode
E Comments & Strings
e Estimation Factors
F File List Input Mode
f Function Metrics
H HTML Output Mode
h Help Manual
i Inheritance Tree
k Keys for sorting
l Function Name List
m Macro Analysis
N Quality Notice Format
n Quality Notices
O Output to a File
o Object Class Analysis
p Printable Code Format
R Read File Options
r Recursive Input
s LOC Summary
T Totals Only
u User Log
v Verbose Metrics
w Work File Differentials
--------------9A401C9600485937F05072E9--