openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <>
Subject Re: java.util.concurrent
Date Fri, 02 Jun 2006 19:57:48 GMT

Abe White wrote:
>> 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
>> 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.

But not everyone favors it.  For a project like this, where there are
multiple people working on things, having the imports called out really

What's the downside?

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

seems reasonable.

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

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.

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

How about just configuring IDEA/Eclipse to do it right, and fixing
things as we go along?


View raw message