<vent>So I've been working on and off with a development team that uses Checkstyle as part of their ANT builds for projects. The check style rules contain all sorts of arcane rules about code style. Just to give you a taste, the following does not pass muster with this rule set;
1: package format.test;
2:
3: import java.lang.*;
4: import format.util.*;
5:
6: abstract public class CheckstyleHatesThisClass {
7: public final static String regex = "\\(.*";
8: public final String terminal = ConstantInjector.fetch("hate.terminal");
9:
10: abstract public String getDataString();
11:
12: final public String return_parenthetic_part() {
13: final String target = getDataString();
14: if ( target.matches(regex) ) {
15: return SlicerDicer.extract(regex,terminal,target);
16: } else {
17: return "";
18: }
19: }
20: }
Begets the following list of complaints from check style;
- line="3" severity="error" message="Using the '.*' form of import should be avoided - java.lang.*."
- line="3" column="1" severity="error" message="Redundant import from the java.lang package - java.lang.*."
- line="4" severity="error" message="Using the '.*' form of import should be avoided - format.util.*."
- line="6" column="10" severity="error" message="'public' modifier out of order with the JLS suggestions."
- line="7" column="18" severity="error" message="'static' modifier out of order with the JLS suggestions."
- line="7" column="32" severity="error" message="Name 'regex' must match pattern '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'."
- line="10" column="14" severity="error" message="'public' modifier out of order with the JLS suggestions."
- line="12" column="11" severity="error" message="'public' modifier out of order with the JLS suggestions."
- line="12" column="25" severity="error" message="Name 'return_parenthetic_part' must match pattern '^[a-z][a-zA-Z0-9]*_?[a-zA-Z0-9]*$'."
- line="13" column="22" severity="error" message="Name 'target' must match pattern '^([A-Z0-9]*_?)*$'."
- line="14" column="18" severity="error" message="'(' is followed by whitespace."
- line="14" column="40" severity="error" message="')' is preceded with whitespace."
- line="15" column="51" severity="error" message="',' is not followed by whitespace."
- line="15" column="60" severity="error" message="',' is not followed by whitespace."
- line="16" column="14" severity="error" message="'}' should be alone on a line."
Now I get that people like to have it 'their way' and can be particular about coding standards, but this is just nuts. I'm not a fan of 'import blah.*', but should that be an error? Or how about white-space between the opening parenthesis and the expression in an if statement, I'm mean come-on people. THis is just stilly.
I'll give you, I combine all the faux pas I could recall to make my example. But it has not been uncommon for me to do a build and then spend upwards of an hour tracking down and correcting these 'check-style errors'.
Now, before someone goes off an gets all snippety with me about 'coding standards are important', I don't disagree with that. I think code should be formatted in a readable manner that is acceptable to any casual reader. If it has a few peculiarities, that's OK too. But here is where the retardation comes in, check-style is reactively telling me that I'm doing something 'wrong' when in fact I'm doing something that, while obnoxious, isn't actually 'wrong'. There is a grey area here.
Wrong would be doesn't compile. Wrong would be it's unreadable. Wrong would be offensive or inappropriate.
Wrong is not visually unappealing. Wrong is not something other than I would have done.
There is no defensible case for these kinds of rules. None what-so-ever. I know, I've tried to make the case.
Here's a great idea, everyone go get a code formatter, or use the one installed in your IDE. And format the code BEFORE you compile it, without complaint, and be done with it. [Did you know that Eclipse can run the formatted every time you save a file, automagically!]
The pragmatic thing is, does the code do what it's supposed to do? Does it solve the businesses problem? It's totally irrelevant if some dried up bean counting sycophant wants to appease the 'code format gods' with some set of archaic rules about where curly braces go. We can make that appeasement, but lets do it with a proactive solution.
Anyway, this has been making me nuts and wasting a lot of my time for two months. The only upside is, I get paid to make the corrections. But I feel dirty, wrong, and used making these kinds of fixes; as if I'm not a the jock I like to think I am because I can't un-train myself from years of putting a close curly before the word else or not capitalizing final variables inside a method.
<vent/>
