Craig McClanahan wrote:
Although the general principle is sound, there can be a counter-argument that cut-n-paste can sometimes avoid undesireable cross-package dependencies. Most rules engines I've seen allow you to create an exceptions list where the developers say "yes, I know this violates the style rule, but we want it this way anyway." Does CheckStyle have that feature?
CheckStyle does allow some per-rule configuration, but I honestly have always just used the rules in their default forms, so I'm not sure what can or can't be done specifically.
But, looking at the docs right now, for this rule it looks like the only relevant option is the the property min, which is the minimum number of lines that must be equal to be considered a duplicate. Might be something to play with.
I assume we also want to prohibit wild card imports? Besides driving me nuts, they are also semantically dangerous.
I couldn't agree more... that one was already enabled in the current ruleset or I defintely would have mentioned it :)
"Simply ignoring" doesn't work if you are catching checked exceptions, so again I would hope this could be selectively turned off on individual use cases.
You can set it to ignore a particular exception class name(s), that's it... the rule checks for catching java.lang.Exception, java.lang.Error or java.lang.RuntimeException. The rationale is that you should be checking for subclasses, something I personally agree with... that's why I said some situations can be acceptable to ignore... if you *know* there is a reqson you are catching Exception, then it's ignorable (IMO).
Personally, I've been burnt enough times by assuming developers know what the operator hierarchy is to err on the side of redundant parentheses whenever there is any possible doubt. On the other hand, I could easily be convinced that redundant parentheses around a return value don't add anything useful, so it wouldn't bother me to need to remove those. Without examining the current reports, I'll bet this one triggers a bunch of warnings on the Struts code base.
I stopped counting at around 300 :) Judging by how far down I was in the report, I'd bet there around around 600-800 of them.
Unfortunately, that rule doesn't seem to have any configuration options, so it'd be a judgement call... I certainly see where your coming from, so I'll just say that if there was some consensus on the point I'd be willing to do the leg work... as you said, parens around returns can probably be removed, but maybe everyone thinks erring on the side of more parens in other places is better... I don't think I'd be convinced, but I understand the rationale and would go along with the crowd :)
We can catch tabs instead of spaces? Cool! :-)
Yeah, that one I like too :) I also love the one that checks for lines longer than 80 characters.
Craig
Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
