tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r1042786 - in /tomcat/trunk/java/org/apache: catalina/core/ catalina/loader/ tomcat/util/threads/
Date Tue, 07 Dec 2010 13:28:24 GMT
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(
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.
> 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).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message