Peter Williams wrote:
> 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.
Right and hence the first solution of just reporting the results. A
developer can very well choose to ignore some of them and proceed with
the checkin. Basically I was thinking more on the lines of, "We should
be able to incorporate the good tools into normal development process
even if it may not be the case completely". So it's more of an extension
to the existing idea and perhaps a solution for the original question.
Nandini
>
> 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