Code coverage analysis

Hello all,

I have a legacy driver with a lot of dead code and I want to refactor this code.
Anyone know a tool to Code Coverage Analysis or Dead Code Static Analysis to make my work easier?

Thanks.

PC-Lint will do some dead code static analysis and particularly unused
variable analysis (including structure members). On code coverage the
best tool is Bullseye Coverage see http://www.bullseye.com/

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:

> Hello all,
>
> I have a legacy driver with a lot of dead code and I want to refactor this code.
> Anyone know a tool to Code Coverage Analysis or Dead Code Static Analysis to make my work easier?
>
> Thanks.

For static or dynamic analysis?

I use the Intel XXX XE … whatever the marketing department is now calling
them … tools in conjunction with /Wall and a code analysis tool called
Understand. The combination of these gives reasonable results, but many
false positives means that I have low confidence that there aren’t false
negatives too and the final test is simple code review. In particular, I
find that exception handlers of all descriptions cause tools to produce
erratic results

wrote in message news:xxxxx@ntdev…

Hello all,

I have a legacy driver with a lot of dead code and I want to refactor this
code.
Anyone know a tool to Code Coverage Analysis or Dead Code Static Analysis to
make my work easier?

Thanks.

Most “code coverage” tools report on actual execution, but does not reveal
code that is not used at all; for example, it will report that
ReportFatalError has never been executed, but if your app never had
whatever it deems a fatal error, then that function was not called. So it
does not distinguish between unreachable code and merely unexecuted code.

Static analysis, such as Gimpel Lint (which does flow analysis) is more
reliable.
joe

Hello all,

I have a legacy driver with a lot of dead code and I want to refactor this
code.
Anyone know a tool to Code Coverage Analysis or Dead Code Static Analysis
to make my work easier?

Thanks.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Joe,

For dead code that is truly correct. But I also contend that good
fault injection is desirable to exercise these seldom used paths, and
then code coverage can help the overall improvement of code. Another
use of code coverage is to identify pieces that are not executed, so
that in code reviews extra effort is spent on reviewing these hard to
reach areas. What should not happen is falling into the trap of saying
we must have X% code coverage, that can lead to lousy code. In my first
exposure to code coverage I worked at a government lab that had a
required 90% code coverage, do all the error handling to make things
nice on a failure was ripped out to up the coverage numbers.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@flounder.com” wrote in message
news:xxxxx@ntdev:

> Most “code coverage” tools report on actual execution, but does not reveal
> code that is not used at all; for example, it will report that
> ReportFatalError has never been executed, but if your app never had
> whatever it deems a fatal error, then that function was not called. So it
> does not distinguish between unreachable code and merely unexecuted code.
>
> Static analysis, such as Gimpel Lint (which does flow analysis) is more
> reliable.
> joe
>
>
> > Hello all,
> >
> > I have a legacy driver with a lot of dead code and I want to refactor this
> > code.
> > Anyone know a tool to Code Coverage Analysis or Dead Code Static Analysis
> > to make my work easier?
> >
> > Thanks.
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >

Code coverage is a tool, not a religion. Anyone who confuses these facts
is in trouble.
joe

(By the way, I didn’t realize that was your story; I’d heard it indirectly
and have often quoted it as an object lesson to my classes, back when I
taught).

Joe,

For dead code that is truly correct. But I also contend that good
fault injection is desirable to exercise these seldom used paths, and
then code coverage can help the overall improvement of code. Another
use of code coverage is to identify pieces that are not executed, so
that in code reviews extra effort is spent on reviewing these hard to
reach areas. What should not happen is falling into the trap of saying
we must have X% code coverage, that can lead to lousy code. In my first
exposure to code coverage I worked at a government lab that had a
required 90% code coverage, do all the error handling to make things
nice on a failure was ripped out to up the coverage numbers.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@flounder.com” wrote in message
> news:xxxxx@ntdev:
>
>> Most “code coverage” tools report on actual execution, but does not
>> reveal
>> code that is not used at all; for example, it will report that
>> ReportFatalError has never been executed, but if your app never had
>> whatever it deems a fatal error, then that function was not called. So
>> it
>> does not distinguish between unreachable code and merely unexecuted
>> code.
>>
>> Static analysis, such as Gimpel Lint (which does flow analysis) is more
>> reliable.
>> joe
>>
>>
>> > Hello all,
>> >
>> > I have a legacy driver with a lot of dead code and I want to refactor
>> this
>> > code.
>> > Anyone know a tool to Code Coverage Analysis or Dead Code Static
>> Analysis
>> > to make my work easier?
>> >
>> > Thanks.
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>