openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: java.util.concurrent
Date Fri, 02 Jun 2006 20:25:48 GMT

On Jun 2, 2006, at 12:57 PM, Geir Magnusson Jr wrote:
>
> Abe White wrote:

>> Craig Russell wrote:
>>> Consistency is good. I look forward to helping out. By the way, it
>>> might be good to take a look at the OpenJPA coding guidelines at
>>> http://incubator.apache.org/openjpa/ which I made up (based on the
>>> Geronimo standards. The guidelines can be changed to suit our  
>>> project,
>>> but please take a look.
>>
>> Actually, the coding standards link from the above page goes  
>> directly to
>> the Geronimo project standards.  You seem to imply that maybe you  
>> meant
>> to copy their standards into our own document?.

Sorry for the confusion. I didn't change the Geronimo document at  
all, and the web site does directly link to the Geronimo standards.
>>
>> Anyway, currently we have a formatter that produces code with the
>> following significant differences from the linked guidelines:
>> - Uses package.* imports, rather than importing every class.  I
>> personally favor this approach because dependencies tend to be
>> package-level anyway, and it's what we've historically used with  
>> Kodo.
>
> But not everyone favors it.  For a project like this, where there are
> multiple people working on things, having the imports called out  
> really
> helps.

I also like explicit imports, because it's easy to see what you are  
doing. It really helps if you see a class in the middle of the source  
that you're not familiar with to be able to go to the imports list  
and actually tell whence it cometh. Of course, a good IDE can also  
tell you that, but I don't think we should rely on IDE tricks.
>
> What's the downside?
>
>> - Indents line continuations one logical tab (4 spaces), rather than
>> indenting 2 tabs or attempting to align the continued line with the
>> previous (for example, aligning method parameter declarations).
>
> seems reasonable.

I'm not really too concerned about this one. Readability is the most  
important thing. If I have a tool that automatically does this for  
me, fine. But I wouldn't refuse a patch because of a missing (or  
extra) indentation on a continuation line.
>
>> - The formatter retains inconsistencies in our existing source.  I
>> believe the only noticeable one is that the SolarMetric developers  
>> all
>> like to break continued lines at different points (before opening  
>> paren,
>> after opening paren, before dot in call chain, after dot, etc).
>
> I'm a "before dot" man myself so it's clear from just looking at the
> beginning of the line it's a method/field.

I also prefer before dot but have no preferences wrt before/after paren.
>
>>
>> We tried the free version of Jalopy and it didn't work well for  
>> us, so
>> the formatter I'm referring to is an in-house formatter I wrote that
>> doesn't create a syntax tree -- it just looks for certain SolarMetric
>> formatting constructs with regexps and changes them to be more Sun- 
>> like
>> in style.   So if we want a different style, we'll probably have  
>> to see
>> about purchasing a commercial formatter, since my regexp approach is
>> very limited.
>
> How about just configuring IDEA/Eclipse to do it right, and fixing
> things as we go along?

I use Netbeans and it does auto-import and auto-space-indent but  
doesn't have other formatting enforcement rules as far as I know. I  
guess if there is a tool that you can run against patch files I'd be  
willing to use it before a checkin...

Craig
>
> geir
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message