If we are going to use code reformatting tools like Jalopy, then
perhaps we do not need Checkstyle to vet mechanical problems, like
line-length. If we set Jalopy to seek an 80 character line length, we
could set CheckStyle for, say, 120, to give us some leeway for lines
that are hard for Jalopy to wrap.
As to the styles like
} else {
versus
}
else {
personally, I can't say I very much care. If Jalopy wants to wrap it
that way, that's fine with me. So long as the style is reasonable and
consistent, I'm a happy camper.
If we take LineLength, Whitespace, and the Curlies out of the
equation, then we are down to 1603 checkstyles errors in Action, that
seem to describe errors we actually deserve!
* http://people.apache.org/~husted/checkstyle/checkstyle-report.html
There are a couple of missing headers, but the rest seem to be true
bad practices, like magic numbers and missing Javadocs.
I would suggest that a reasonable goal would be to use Jalopy to
correct mechanical errors, like line length, and let CheckStyle focus
on eeper coding problems that something like Jalopy can't fix.
I've updated the default checkstyle configuraton to match what I used
to achieve the referenced report and the current state of the
Action/Action package. If this seems all right, I could conform the
JavaDocs on the rest of the Acton subproject, and move on to the
others.
One note: In the checkstyle configuration, I also disabled the check
for Inline conditions. I myself don't find this construct hard to
read, and some of us have tended to use Inline Conditionals over the
years.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
