Nandini Ektare wrote:
> vince kraemer wrote:
>
>> like checkstyle, PMD or FindBugs as part of their "normal"
>> development process?
>>
> Not sure how difficult it is but I wonder what does it take to
> integrate these tools to existing configuration management scripts.
> That way it automatically becomes part of normal development process...
>
> For e.g. During an attempt to checkin, detection of undesirable code
> styles would trigger an action which could be
> 1.displaying those to the developer
> 2.as rigorous as checkin is not permitted
> 3.or a warning mail to the desired alias post checkin
IMO, far too much human interpretation is currently required of the
results to eliminate false positives to allow any of these options to be
practical at this time. This goes for FindBugs and PMD as I've used
those two. Not sure about any others, but I would expect there as well.
That said, Vince's original question still holds. This is primarily an
individual programmer discipline issue. Since it is not practical to
enforce usage, it is up to individuals to choose to incorporate the
results of these tools into their daily work, fix the genuine bugs they
uncover, perhaps make trivial code adjustments to eliminate errors that
are not bugs, but still easy to fix. The remaining issues would be
"alleged bugs that are not bugs", no boilerplate solution here.
Sometimes, reporting as a bug in the tool might make sense, other times,
all you can do is ignore it and/or turn off the flag that caused the
erroneous warning.
-Peter
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>