Sorry for the delayed reply. On Mon, Jun 23, 2008 at 2:46 PM, Dave Thompson <[EMAIL PROTECTED]> wrote:
> My opinion is that compiler warnings can be helpful, as they sometimes > highlight faults in the code, which aren't otherwise noticed. They also > draw attention to deprecated methods, and unused variables. However, if a > small number of new warnings are masked by thousands of historic ones, the > warning mechanism as a development aid is almost useless. > > What is the official line on this? Would anyone object to a tidy-up, where > we tried to reduce the number of warnings? Is this activity worthwhile? You're received the "official line," but just to interject my opinion, I believe in the value of them in principal, but there are a number of problems in practice. To be useful, there are really only two states - none and some. Now this can be applied at different levels of granularity, so we can have lots of modules with "none" that we can monitor for going to the "some" state, but once there are "some" more than a few places, the whole thing degrades. Here are some of the problems I see: - Rule setting and rule keeping are asymmetrical activities. With a couple of key strokes, someone can decide that all lines now wrap at 78 characters instead of 80 and create huge amounts of work for everyone else who have no recourse for their objections. Almost exactly this scenario happened with Javadoc for overridden methods. - The tools don't provide good support. This exacerbated the Javadoc situation and even plays into simple things like line wrapping. Eclipse, quite reasonably in my opinion, considers a line that only has a couple of punctuation characters hanger over the margin to be conformant, while Checkstyle is no where near as liberal. If Eclipse's ctrl/F (ie format) doesn't do the right thing, I'm unlikely to care. - A corollary to the above, but complicated by our peculiar API design, are warnings for untyped collections. Since all of our model elements are opaque Objects, we have lots of these. I won't change a List to a List<Object> because that's just silly when it's a List<ModelElement> and I won't add an annotation to turn off the warnings because I want to be able to find them if the API ever gets fixed, so we've got lots of these polluting the source code. Having said all that, I do review every module that I commit to see if I can get the little yellow flag turned off. Modules that I'm just reading while debugging a problem will often get cleaned up if I have extra time. On the other hand, I'll often miss things if I'm in a rush. The only way to make this work is a) with a reasonable set of rules and b) with good tool support. If getting to zero errors is impossible (likely), the only thing that will help is continuous feedback. Graphs like the Hudson CI server showing trends are useful on a global scale, but you really need specific local feedback like "the commit you just made improved/worsened things by N errors" or "your packages are #1 in the list of faults per line of code." Individual efforts to fix things, lacking any process or tooling improvement, are heroic, but doomed to failure, like shoveling against the tide. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
