openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: java.util.concurrent
Date Sat, 03 Jun 2006 14:20:24 GMT
I'm using IntelliJ (Eclipse does the same thing) so that you set the coding standards in a
and it will auto indent, line break, handle imports, etc.  It would be a plus if we followed
development patterns from the existing projects as it will reduce the effort when people work
projects and go back and forth.

Also, Abe, you mentioned a tool.  Are you donating that to the project (it might already be
in the 
tree :)


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'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 easily. 
> _______________________________________________________________________
> 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