Update to checkstyle rule set

As an unrelated checkstyle comment, I've found that the eclipse checkstyle plugin REQUIRES backslash-style folder names to function under Windows, but of course cannot use such names under Linux. How annoying. That means that someone working under UNIX has to hand-modify the .checkstyle file to point to somewhere meaningful under UNIX.

Following changes sound reasonable to me:

• allow empty blocks with comments
• extend line length from 90 to 100 characters
• allow FIXME and TEMP as todo comments

I don' tlike to relax:

• design for extension as most areas of code where this apears should be changed and we would not have a signal for that without the rule

Can you please explain a bit on the rest of of the rules.

On design for extension – it generates SO MUCH noise!!! Do you believe that most places we see this we should change the code? That means making all public non-empty non-abstract methods final to prevent someone from extending a class, which doesn't seem friendly.

The other rules:

• Parameter assignment - goal: prevent people from changing the value of a method parameter
  *MultipleVariableDeclarations - goal: prevent on one line: float a; int i; String name; as those should be on separate lines. This would need a tweak to not give unnecessary complaints on a for() statement
• MultipleStringLiterals - goal: catch places where the same string literal occurs more than once in a source file – needs to be tweaked as it's currently too sensitive, so I have it listed but off
• ModifiedControlVariable - goal: prevent one from changing "i" if it is the control variable of a for() loop
• JUnitTestCase - various correctness checks for any class that is a JUnit test csae
• FinalLocalVariable - too much noise for now, but if a local variable is assigned once and never changed, note that it can be set to final
• CovariantEquals - check for equals(String) or anything other than equals(Object) to prevent places where people WANT to override equals() but provdie the wrong method signature
• JavadocStyle - do checks on the correctness of JavaDoc comments

According to yur explanation I am fine with all changes but not with removeal of the design for extension info complaints. We don't need to make all public non-empty non-abstract methods final as the complaints are at info level. The main reason is that they are the only way to force people to think if the method should be not final by intention or if they simply forgot to declare it final. Therefore I suggest to go for the rest of the changes.