lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <>
Subject Re: Code Formatting
Date Mon, 10 Nov 2008 16:13:25 GMT
It seems to me that the following would work:
1) All new code (contrib too) has to be formatted according to  
published standards. This can be done either by the person doing the  
submission, by a committer, or .... (It doesn't matter to me)
2) All existing code for which there is no patch can be changed today.  
People who are working on future patches can merge the changes into  
their code, possibly with some difficulty.
3) Code for which there are patches is problematic. But I would think  
that if one is applying the last patch to a file, one could then  
follow that with a format change.

-- DM

On Nov 10, 2008, at 7:29 AM, Grant Ingersoll wrote:

> 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:
>>> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message