Kathey Marsden wrote:
First I want to say that I hope the community will continue to vote on
this issue while discussion is underway about whether or not Rick will
veto. I am sure the next person to take a shot at this will appreciate
knowing where everyone stands even if it doesn't pass this round. See
http://db.apache.org/decisions.html for responsibilities and
definitions of voting. I think this is a consensus vote.
Rick Hillegas wrote:
Just want to make sure we have realistic expectations for this vote:
Since we are not bulk-reformatting the code, even after this vote
Derby won't conform to the db project guidelines.
Yes, my hope is that incrementally we can reach a point where we
conform to the db project guidelines. The question is how much closer
we can get to that now. I tend to think, the lack of such a
convention for Derby was just a serious oversight in allowing Derby to
graduate incubation.
The guidelines don't specify how extensive the hard-and-fast rules
have to be. To date, here are the only ones I think we have discussed
extensively:
1) No tabs.
2) Indentation stops set at 4 spaces.
3) Line length not to exceed 80 characters.
To this, with the community's approval, I would add
0) Write clearly.
A good enough coding standard would be these 4 hard-and-fast rules
plus a pointer to a non-binding style primer. Let's keep it simple
and focus on the issues which actually bothered us.
If incremental consensus has to start there, I suppose it could, but
I don't think it would qualify as a "well-defined convention" and I do
think we would need to adopt a well-defined convention in the future
in our work to comply with the db project guidelines. I am
curious for matters of db project guidelines, who could answer what
level of specificity is required.
I disagree that this would solve all the issues. I think still there
would be issues with IDE's reformatting code, various religious
discussions around particular changes and the core problem would
remain (even after removal of the note) that a new developer can't
rely upon setting their IDE to some documented convention and be sure
they won't get into trouble with it. I think we need to be setup so
it is easy to join the project and make a fix. Those making changes
for style need to make sure that their style decisions are not going
to interfere with anyone using the documented convention and that is
it. That is not possible with the 4 rules and primer pointer wording.
I'm not sure I understand this point. If we recommend a style primer,
then I think we're saying that the style is safe and we don't expect
committers to flunk a conforming patch for style reasons--provided, of
course, that the code is clear. "Recommended" means "safe". I'm just
saying it doesn't mean "mandatory". I don't think our perspectives are
that far apart.
It is different from closed source where we might expect some small
group of core developers to learn how to work around and integrate
each other's styles. ( I actually have a .emacs file that seems to
have the beginning of this conversation years ago, I am not even sure
who wrote it or who "I" is in this context, but it has various
commented out sections and says .." Nat's favorite is ... Ame's said
.... I like it like ... We still haven't decided about switch
statements" etc.) This kind of thing does not scale well to an open
source project with potentially hundreds of contributors all showing
up to build great extensions and and make fixes just want to know
some format to use that won't get them into trouble. They don't
really care what color the shed is, just give them something that
works and if we are not militant about it and allow variations that
make sense and don't interfere, then we are covered.
I think we can always tighten up the rules if we discover that we are
flunking patches for recurrent reasons. So far, it's mostly been an
issue of tabs/spaces/line-lengths.
I think we should publish the convention as proposed and our ultimate
goal should be that anyone formatting their code in this way is not
going have to ever redo their patch based on formatting issues.
Please see my earlier comment. I think we agree on this one.
"Recommended" means "safe" (provided that the patch is clear).
Thanks
Kathey
- Re: [VOTE] Approve coding conventions for the Derby... Rick Hillegas
-
