On Jun 2, 2006, at 1:22 PM, Abe White wrote:
But not everyone favors it. For a project like this, where there aremultiple people working on things, having the imports called out reallyhelps. 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
