Add your comments here...
A code coverage analyzer will help in these ways:
- Expose code that is not exercised by the test suite. Add test cases that will exercise it.
- Identify code that is unreachable. Unreachable code is often the leftover result of program design changes. Unreachable code should be removed, as it can be very confusing to the maintenance programmer.
Please change "maintenance programmer" to "the next programmer"!
Why?? Well, "maintenance programmer" is clearly inferior to "A Programmer". Hence, he's not taken as an equal person (thus, not "one of us"). Additionally, he's the one learning, so he should learn it the hard way, right? What if, at the next job, you (yes you!) end up as the Maintenance Programmer? At least until the Boss gets convinced!
"The D code coverage analyser is built in as part of the D compiler. Therefore, it is always in perfect synchronization with the language implementation. It's implemented by establishing a counter for each line in each module compiled with the -cov switch. Code is inserted at the beginning of each statement to increment the corresponding counter. When the program finishes, a static destructor for std.cover collects all the counters, merges it with the source files, and writes the reports out to listing (.lst) files."
The -cov switch inserts code that counts how many times each of the functions and procedures in the D source code have been executed. This is accomplished by creating a counter for each procedure, and incrementing that counter each time the procedure is entered. At program exit, these values are written into a file, (.lst) which can then be examined to get a precise overview of the runtime behaviour of the program. Compared with the existing methods of achieving this knowledge, the D -cov compiler switch is superior: it comes free (as in beer), it analyzes the code in the actual runtime environment, and it does not cause noticeable delays in program execution speed.
Mind you, my comments here, are based entirely on an assumption upon what the switch does! If these assumptions turn out to be incorrect, then please, delete this entire section from this page.
-- Georg Wrede (December 10, 2005)