source code analysis/code coverage tool experience

[bill turner]

Hi All,

I am wondering if anyone has any experience, can recommend, any open
source public licensed source code analysis and code coverage tools,
such as PMD, jester and jlint.

For both, I am interested in how well they seemed to work, how well
they integrated with the ide (if intended to do so), how well they
integrated into build tools (ant, cruise control), and how easy it was
to understand the reporting.

For the source code analysis, I am especially interested in anything
you say about the complexity measures performed.

I've found a couple website listing several such tools but don't have
the time to research them all. Any feedback that can be provided to
short-circuit the testing of such tools is truly appreciated!

Here are the websites I found:
http://www.oneclipse.com/plugins/analysis-plugin-topic/topic_view
http://java-source.net/open-source/code-coverage
http://java-source.net/open-source/code-analyzers

Thanks much!

bill

 

[Ingo R. Homann]

Hi bill,

Hi All,

I am wondering if anyone has any experience, can recommend, any open
source public licensed source code analysis and code coverage tools,
such as PMD, jester and jlint.

I do not really know what your requirements are since I do not know PMD,
jester and jlint. I have so far worked with checkstyle and emma:

For both, I am interested in how well they seemed to work,

checkstyle does some static code analysis and has different rules to,
well - check the style of your sources. Some rules are rather
unimportant and more or less useless, some are even wrong (e.g. they
forbid usage of special chars like german 'umlaute' [äöü] which are
explicitly allowed by sun) but some are really useful (check if equals
is override, then hashCode must be override as well, find switch "fall
through", modified control variable outside of loop header, ...)
Fortunately, most rules can be configured. You can write your own rules
as well, if you want so, IIRC. I must say that I have diabled about 50%
of the rules, but I'm stisfied with the rest.

emma is a nice tool for testing code coverage which is especially useful
when unit testing. You can do this either on-the-fly (by starting
programs not with "java" but with "emmajava" - that's all, very easy!)
or by 'instrumenting' your java classes, that means, let emma modify
your classes in a certain way.
The latter method is useful, when you do not start your program
yourself: e.g. when doing JUnit-tests, they are started with "<junit>"

how well
they integrated with the ide (if intended to do so),

checkstyle: integrates very well with eclipse

emma: does not intergrate with eclipse (or any other IDE AFAIK).

how well they
integrated into build tools (ant, cruise control),

emma: Works good with ant.

and how easy it was
to understand the reporting.

checkstyle: Integrated in Eclipse, its very easy: In the
error/warnings-view there are expressive descritions of what is wrong
(or "seems wrong to cs" ;-) with your code

emma: very easy to understand and quite substantial, I think. You get a
tabular with your classes and methods, ordered by the percentage of
methods, blocks or lines that where covered/not covered. You can even
generate a HTML-view of your sources in which the lines that are not
covered are marked red. Goes down to sub line level (marks "int
a=b?0:1;" yellow if only one branch is covered)! I only miss some
tags/annotations for disabling parts of code: sometimes there is code
you *cannot* cover although it is syntactically necessary ("case 1:
return x; case 2: return y; ... default:
/*neverHappensButNeedsAReturn*/throw new RuntimeException();") Of
course, emma always complains that this code is not covered and (AFAIK)
you cannot tell emma that it should not be covered.

Ciao,
Ingo

 

[bill turner]

thanks. sorry for the late reply. i posted then had to leave town...

as for my requirements, they are fairly nebulous. i have just joined a
team to improve performance and stability. we are installing a tool
called Introscope to monitor the applications. however, since i have
long had an interest in quality and process, it seems the best place to
make long term improvements is before application deployment. i also
feel that static source code analysis, especially complexity measures,
could be used to identify potential hot spots, spots that i could make
sure are probed via introscope. since i am part of the enterprise team
and we are rolling this out to other teams, i was hoping to demonstrate
such a tool to the application in areas in this capacity, then suggest
that it be incorporated into eclipse and ant. i was hoping they would
see the benefit of source code analysis. i would also, in the same
breath, recommend code coverage tools and maybe even beautifiers so
that all the source code would have the same feel. some of this may
have to wait for a second phase when we are concentrating more on
process rather than the current fires. my purpose in asking for
recommendations should be obvious.

this also brings up the larger topic of whether or not people find
complexity measures useful. it is my belief, and i only have anecdotal
information to support this, that complex code has a higher propensity
for failure.

likewise, it seems that code coverage tools should be useful. then
again, they could be overkill and may bring development to a crawl.

thanks, again, for the input!