I echo Patricia, +0.5 for option 1 for the same reasons. I like these two: > No plowing through source to convert all tabs into spaces (with the only > intent of conversion) > No contribution will be refused based on indentation and tabs issues.
But what does this mean? > Standard no reformatting only commits. That, when I come across a poorly formated source file (or which there are many) I can't do a reformat and commit? (And here I'm talking about more than just tabs vs spaces). If so, I think that's possibly a mistake, committing reformatting changes at that same time as meaningful code changes can make reading a diff much harder. Other than that, +1 on Sim's proposal. The outcome of this needs to make it onto the website as well. I would suggest that the "Code Conventions" page includes the outcome of this vote, a link to the mail archive, and a link to the Sun-specified coding standards. I don't see the value in trying to enforce any other code convention. On Thu, Dec 9, 2010 at 7:50 AM, Sim IJskes - QCG <[email protected]> wrote: > On 12/09/2010 03:15 AM, Patricia Shanahan wrote: >> >> Option 1: An indentation step is four spaces. > > +1 > > Proposal: > > Standard indent is 4 spaces. > Standard we use no tabs. > No plowing through source to convert all tabs into spaces (with the only > intent of conversion) > No contribution will be refused based on indentation and tabs issues. > Standard no reformatting only commits. > > Standard meaning standard. Not rule. > > Gr. Sim >
