Mark Thomas wrote:
...
JavadocType (versionFormat) -> currently 539 failures
Not sure what exactly you are proposing here. Could you clarify?
I mean the format of the @Version JavaDoc tag what Konstantin Kolinko
has started to fix:
http://tomcat.markmail.org/thread/bfry4x5gwbhezo6x
...
Additionally it seems that you pay attention at some warnings emitted by
your IDE. It would be interesting to express these rules as checkstyle
(or whatever) rule that can be checked automatically. Can you list the
Eclipse style warnings you try to fix?
Just the standard Java compiler warnings.
is there an agreement among the committers for that? ;-)
I would be cautious with Eclipse warnings. Some of them don't make sense
(or at least not alone like "Serializable class without
serialVersionUID") and others have pros and cons (like removing the
"else" when the "if" ends with a return)
I agree that coherent code style is only cosmetic in a first time as it
doesn't change the resulting byte code. Nevertheless it makes easier to
concentrate on the important things: the code content, without being
distracted by the form. Therefore it helps to find real problems and
make easier to compare files, apply patches, ...
But it makes it harder to back-port changes. I'm not against cleaning up
the code, we just need to be aware of the consequences of doing so.
Two solutions for easy back ports
1) never make change, neither yet, nor in the future and keep
everything, even if dirty
2) apply clean style rules on all maintained code versions
Of course I prefer (2) ;-)
Cheers,
Marc.
--
Blog: http://mguillem.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
