[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The method chosen for parsing the source has an effect on what gets seen (scored) by the program.
2.1.1 Complexity Measurement Parsing | ||
2.1.2 Post-PreProcessing Parsing | ||
2.1.3 During PreProcessing Parsing | ||
2.1.4 pmccabe Parsing |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This program examines the actual source a human looks at when the
file is opened, provided it is not pre-processed by unifdef
,
See section unifdef
. This was chosen because
uncompiled code adds to the complexity of what a human must understand.
However, sometimes the source will contain unbalanced braces a la:
#if FOO for (int ix = foo;;) { #else for (int ix = bar;;) { #endif code... } |
rendering code that cannot be parsed correctly. unifdef
-ing
makes it parsable. Unfortunately, because the practice of ifdef
-ing
unbalanced curly braces is so common, this program cannot rely on
finding the correct closing brace.
CAVEAT: for the purposes of this program, procedures end when either a matching closing brace is found or a closing curly brace is found in column 1, whichever comes first. If the closing brace in column one does not match the procedure opening brace, the procedure is considered unscorable.
Fortunately, unscorable procedures are relatively unusual.
CAVEAT2: K&R procedure headers are not recognized. If anything other than an opening curly brace appears after the parameter list will cause the code recognizer to go back into “look for a procedure header” mode. K&R procedures are not just not scored, they are completely ignored.
This should probably get fixed, though.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Another approach would be to use the C
compiler and analize the
tokens coming out of the preprocessor. The drawbacks are that macro
expansions will add to the complexity, even though they do not add to
human perceived complexity, and uncompiled code do not add to the
complexity measure. The benefit, of course, is that you know for
certain where a procedure body starts and ends.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This would require going into the C preprocessor code and cause macros to not be expanded. Again, the great benefit is that you know for certain you can find the starting and ending braces for every procedure body. The downsides are the extra work and, again, the uncompiled code won’t get counted in the complexity measure.
This might be a useful exercise to do some day, just to see how helpful it might be. Being able to recognize all procedure bodies without fail would be a good thing.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
pmccabe
ParsingThe pmccabe
parsing actually inspired the method for this program.
Thd difference is that pmccabe
will always keep scanning until
a procedure body’s closing curly brace is found, even if that means
counting the code from several following procedure definitions.
The consequence of this is that this program’s code will see some
procedures that pmccabe
will not, and vice versa.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Bruce Korb on May 15, 2011 using texi2html 1.82.