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:33:10 GMT

On Jun 2, 2006, at 1:22 PM, Abe White wrote:

>> 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.
>>
>> What's the downside?
>
> Just that it's verbose and makes writing imports by hand take  
> longer.  But I don't feel strongly about it.  I'm find with  
> explicit imports if that's the consensus.
>
I've already given my rationale why I like explicit imports.
>
>> 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'm an after dot person, but again I'm fine with whatever,  
> including not enforcing any particular policy on this.

I don't feel strongly enough to require a standard.
>
>> How about just configuring IDEA/Eclipse to do it right, and fixing
>> things as we go along?
>
> I like the idea of using an IDE to fix everything.  I don't use an  
> IDE myself, so I don't know whether it can make the necessary  
> fixes.  Here's a list of changes necessary to get SolarMetric code  
> looking more like the standards we've outlined:
> - Change to explicit imports.

yes

> - Move opening brace to same line.

yes

> - Move up "else" and "catch" to same line as previous closing brace.

yes

> - Move up "extends" and "implements" to same line as class  
> declaration.

yes

> - Move up "throws" to same line as method declaration.

yes

> - Remove spaces before opening parens on method calls.

don't really care

> - Change tabs to spaces.

yes

> - Remove extraneous spaces from field declarations (we tend to  
> align declarations with tabs, so converting the tabs to spaces make  
> sit look horrible... plus I'd like to just stop aligning  
> declarations altogether anyway).

don't care about extraneous spaces or aligning declarations, but  
would like to remove tabs

> - Remove extraneous spaces from Javadoc (again, we use tabs to  
> align things a lot).

don't care

> - Collapse double-blank lines into a single blank line (we use 2  
> blank lines for block separators a lot).

don't care

> - Make above changes without creating lines over 80 chars.

yes
>
> My formatter does all the above except the explicit imports, and it  
> sometimes create lines over 80 chars when moving up extends/ 
> implements/throws lines.  Not mentioned on the list: it's also able  
> to take a previously-continued line and turn it back into a single  
> line if the above changes cause the single line to now be <= 80 chars.
>
> If IDE's can't do that, then perhaps a hybrid approach where we use  
> my formatter to get everything most of the way there, then use an  
> IDE to get the explicit imports as we go along.  This also has the  
> advantage of getting everything into an almost-there style in one  
> fell swoop, rather than having two totally different styles until  
> someone with an IDE opens all the files eventually.
>
> Note that until we can get everything necessary from Kodo into  
> OpenJPA, we probably don't want to mess with formatting, because we  
> have to be able to merge changes back and forth between the  
> codebases easily.

I like the idea of a massive change early in the cycle (before the  
initial checkin is fine, or sometime shortly thereafter). For the  
first week or so, I'm mostly going to be reading the code anyway.

Craig

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