I did a quick search of the source code of River 2.1.0 (it's what I had handy)
*.java, number of tabs: 123176 *.java, number of 4-spaces: 192828 *.xml, number of tabs: 10366 *.xml, number of 4-spaces: 6918 and many (most?) of the files have a mix of both. So, I make the counter-proposal that it's too late to fix this without a lot of pointless code churn. I think we need to forbid formatting fixes that just change tabs to spaces or vice versa. Even when done as separate commits, those changes wreak havoc on diffs when trying to troubleshoot regressions. I say developers just need to set their IDE to 8-chars for tab for this project and live with it. That said, I think it's fine to have a tabs-only or spaces-only policy for *new* code. The ffmpeg project, as an example, has a VERY strict checkin policy that says whitespace has to be perfect before they accept a patch. That's the only way to get a clean source tree with a lot of developers. Chris -----Original Message----- From: Sim IJskes - QCG [mailto:s...@qcg.nl] Sent: Thursday, December 09, 2010 8:57 AM To: river-dev@incubator.apache.org Subject: Re: [VOTE] Re: Formatting of River Source Tree On 09-12-10 15:49, Sim IJskes - QCG wrote: > http://river.staging.apache.org/river/coding.html BTW, i really hate some of the coding conventions in "Code Conventions for the Java Programming Language". I've written and maintained software and if it is clear, then its ok. I can read other ones code, and write according to my own. I see no problem to have multiple styles in a single file. Gr. Sim -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
