openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
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
template 
and it will auto indent, line break, handle imports, etc.  It would be a plus if we followed
general 
development patterns from the existing projects as it will reduce the effort when people work
on 
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 :)

Matt

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.
> 
> 
> 

Mime
View raw message