logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: [POLL] Source code formatting conventions
Date Fri, 03 Sep 2004 13:54:47 GMT

It's always interesting to see how two people can approach the same feature with such different
goals ;)  I agree with the coding convention and the FAQ's guidelines on contributing code,
no issues there.

I see code formatting as more than the indentation issue, though.  I think there's value in
sorting sections of a source code file, enforcing modifier order, and general consistency
around whitespace and style.  If all we care about is indentation we don't need a formatter,
just a one-line perl script to replace a tab with two spaces.

Anyways, I don't care that much ;)  I agree with the coding convention, I don't mind removing
the Jalopy dependency, and since I don't use Eclipse I'll just run that perl script ensure
the indentation standard is adhered to before committing any code.

Yoav Shapira
Millennium Research Informatics

>-----Original Message-----
>From: Ceki Gülcü [mailto:ceki@qos.ch]
>Sent: Friday, September 03, 2004 9:40 AM
>To: Log4J Developers List
>Subject: RE: [POLL] Source code formatting conventions
>At 02:52 PM 9/3/2004, Shapira, Yoav wrote:
>>You're right that development has stopped on the open-source version of
>>Jalopy, and that's a negative.  However, Jalopy still works well and IIRC
>>still supports a superset of the Eclipse formatting features.
>Do we really care whether Japoly is more powerful than Eclipse
>formatting? As long as we reach consensus, I think that I'll be
>satisfied with any formatter that can enforce 2 spaces for indentation
>and correctly places braces.
>>We don't want to require log4j developers to use a specific IDE, even if
>>it's a free one like Eclipse.
>Agreed, but please see my next remark.
>>OTOH, I think we can live with commits not being well-formatted and only
>>doing the formatting prior to tagging a release, right?  If so, i.e. we
>>only require one formatting run prior to tagging a release, then I'm fine
>>with changing to the Eclipse formatter.
>It looks like my take on the matter is more or less the opposite. :-)
>My interest on the formatting problem can be traced back a single
>issue. When a commit occurs, I'd like to be able to hone in on the
>changes by looking at the CVS notification message. When a developer
>makes logical changes to a file and at the same time changes the
>indentation, the notification message is rendered, for all practical
>purposes, useless. See also
>http://logging.apache.org/log4j/docs/faq.html#4.2 in particular items
>2 and 3.
>It is important to avoid formatting "contests" among ourselves. If
>developers X and Y use different formatting rules and decide to
>reformat and edit the same file, the results will be not be amusing
>for long. If we all agreed to use the same formatting rules, then the
>risk for formatting conflicts should be reduced to zero.
>I wonder how other projects deal with this matter.
>>Yoav Shapira
>>Millennium Research Informatics
>Ceki Gülcü
>      For log4j documentation consider "The complete log4j manual"
>      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org

This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message