lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: Code Formatting
Date Mon, 10 Nov 2008 12:29:53 GMT
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: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message