Am Montag, den 06.12.2010, 21:22 +0000 schrieb Mark Thomas:
> On 06/12/2010 20:49, slaur...@apache.org wrote:
> > Author: slaurent
> > Date: Mon Dec 6 20:49:14 2010
> > New Revision: 1042786
> >
> > URL: http://svn.apache.org/viewvc?rev=1042786&view=rev
>
>
> > @@ -63,7 +72,7 @@ public class ThreadLocalLeakPreventionLi
> > try {
> > Lifecycle lifecycle = event.getLifecycle();
> > if (Lifecycle.AFTER_START_EVENT.equals(event.getType())
> > - && lifecycle instanceof Server) {
> > + && lifecycle instanceof Server) {
> > // when the server starts, we register ourself as listener
> > for
> > // all context
> > // as well as container event listener so that we know
> > when new
>
> 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.
In tomcat6.x it is
> egrep -r "&&\s*$" * | wc -l # && at the end of line
217
> egrep -r "^\s*&&" * | wc -l # && at front of line
228
that is slightly in favor of operator after line wrapping.
In tomcat.trunk it is now
> egrep -r "&&\s*$" * | wc -l # && at the end of line
279
> egrep -r "^\s*&&" * | wc -l # && at front of line
264
Which is favors operator before line wrapping.
Java coding conventions and eclipse coding conventions both prefer
operator after line wrapping.
So is operator after line wrapping really a tomcat standard?
>
>
> > - 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 :)
>
> 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.
>
> Mark
Bye
Felix
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
