openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abe White <>
Subject Re: java.util.concurrent
Date Fri, 02 Jun 2006 20:22:48 GMT
> 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'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.

> 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.
- Move opening brace to same line.
- Move up "else" and "catch" to same line as previous closing brace.
- Move up "extends" and "implements" to same line as class declaration.
- Move up "throws" to same line as method declaration.
- Remove spaces before opening parens on method calls.
- Change tabs to spaces.
- 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).
- Remove extraneous spaces from Javadoc (again, we use tabs to align  
things a lot).
- Collapse double-blank lines into a single blank line (we use 2  
blank lines for block separators a lot).
- Make above changes without creating lines over 80 chars.

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  
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

View raw message