On 07/12/2010 12:29, Felix Schumacher wrote:
Am Montag, den 06.12.2010, 21:22 +0000 schrieb Mark Thomas:
That indenting is now misleading (it was fine before) and the operator
is still at the beginning of the line.
I just made a quick lookup for usage of (&&) operator at the end of line
versus (&&) operator at the beginning of the next line. It seems that
usage has changed between tomcat 6 and trunk.
For the stats to be meaningful you'd need to look at all the possible
operators, not just &&. That said, I suspect you'll see a similar thing,
a gradual shift towards operator before line wrapping
Java coding conventions and eclipse coding conventions both prefer
operator after line wrapping.
My preference is for operator before since I believe it aids
readability. YMMV.
So is operator after line wrapping really a tomcat standard?
operator before line wrapping is the direction the code is heading in
and the direction I think it should continue to head.
- log.error("Exception processing event " + event, e);
+ String msg =
+ sm.getString(
+ "threadLocalLeakPreventionListener.lifecycleEvent.error",
+ event);
+ log.error(msg, e);
More auto formatting "helpfulness" by the look of it. No reason for
String msg = sm.getString(
not to be on one line.
It would probably break the 80 character limits :)
I don't get this. I was suggesting the following:
String msg = sm.getString(
"threadLocalLeakPreventionListener.lifecycleEvent.error",
event);
i.e. get rid of the unnecessary line break.
If we can pull some Eclipse settings together to help folks with this
that would be great.
That would be great, if we knew what the conventions were.
http://tomcat.apache.org/getinvolved.html only mentions four
conventions.
I'm not sure on the best way to approach this. The code is not
consistent. The committers don't have a consistent style for new stuff.
I'm not sure how much we can agree on.
What I have been doing is slowly adding rules to Checkstyle. So far
there hasn't been any push back but I'm sure there will be some at some
point. My idea was to add the rules the community was happy with and
where we disagree leave things as they are. Modifier order and redundant
modifiers are the next ones on the list. I'll see if there is an
operator placement one ... there is so I'll add that as well (commented
out until the issues are fixed).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
