> Consistency is good. I look forward to helping out. By the way, it
> might be good to take a look at the OpenJPA coding guidelines at
> http://incubator.apache.org/openjpa/ which I made up (based on the
> Geronimo standards. The guidelines can be changed to suit our
> project, but please take a look.
Actually, the coding standards link from the above page goes directly
to the Geronimo project standards. You seem to imply that maybe you
meant to copy their standards into our own document?.
Anyway, currently we have a formatter that produces code with the
following significant differences from the linked guidelines:
- Uses package.* imports, rather than importing every class. I
personally favor this approach because dependencies tend to be
package-level anyway, and it's what we've historically used with Kodo.
- Indents line continuations one logical tab (4 spaces), rather than
indenting 2 tabs or attempting to align the continued line with the
previous (for example, aligning method parameter declarations).
- The formatter retains inconsistencies in our existing source. I
believe the only noticeable one is that the SolarMetric developers
all like to break continued lines at different points (before opening
paren, after opening paren, before dot in call chain, after dot, etc).
We tried the free version of Jalopy and it didn't work well for us,
so the formatter I'm referring to is an in-house formatter I wrote
that doesn't create a syntax tree -- it just looks for certain
SolarMetric formatting constructs with regexps and changes them to be
more Sun-like in style. So if we want a different style, we'll
probably have to see about purchasing a commercial formatter, since
my regexp approach is very limited.
|