We _could_ do a wholesale change as part of 3.0, and then just make
sure that committers going forward format properly. I've seen other
projects do that.
Also, I'm not sure, but I think Hadoop's automated patch checker can
check to see if a patch is properly formatted or not. We need to add
that for our stuff anyway, so maybe it would help.
On Nov 9, 2008, at 2:59 PM, Michael McCandless wrote:
I too am bugged by inconsistent formatting and must hold back the
temptation to fix it.
And I agree a patch for a real change should not mix-in formatting
changes.
I do worry that wholesale formatting changes will obsolete pending
patches (though really we should try to keep "pending patches" at a
minimum -- hmm I see we have 73 open issues with patch available),
and make someone with alot of pending changes pull all their hair
out after doing "svn up". I'm not sure if that cost makes it worth
it net/net. Plus, unless we get help enforcing the styles over time
(eg the ideas in the Solr thread), things will likely diverge with
time again anyway.
Mike
Mark Miller wrote:
I'd like to clean up a lot of inconsistent code formatting I've
seen. Being consistent across the project would be cool, and its
easy to do with the intelij/eclipse formatting settings out there.
Looks like not so easy to get done though, as you can see from this
solr discussion: http://www.nabble.com/Code-style-td10668515.html
Some good points are made in the thread, the biggest in my mind
being that a ton of patches in JIRA become a major pain to apply/fix.
What about a slower approach maybe? I'd be happy to do a handful of
classes a month or something. Or are there better ideas? Or are we
just stuck on this (not that its a big issue to be stuck on)?
The idea of fixing as patches come in is appealing, but not if most
people doing patches are not in on the game. And it becomes noise
in the patch - I tried to hold myself off from fixing anything in
the last patch I was working on because it just makes it harder for
someone else to look at the patch and just the functional changes
made.
It would be cool to have more consistent code though - especially,
there are some big indenting issue here and there that really bug me.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
