On Saturday 05 March 2005 13:56, Andrew Piskorski wrote: > On Tue, Mar 01, 2005 at 08:10:23PM -0500, Dossy Shiobara wrote: > > On 2005.03.01, Tom Jackson <[EMAIL PROTECTED]> wrote: > > > > Indeed, there's places in the codebase where hard tabs still exist. > > They should be replaced with 4 spaces where appropriate, but only when > > you're actually touching that portion of the code to fix a bug or change > > functionality. > > Why? I would suggest the exact opposite, that it would be more useful > to go through and commit all "untabify" changes at once for each > module.
I would think it is easier to simply apply a few fixes to a single file the next time you touch it, and commit the whitespace changes first, than it would be to only correct the code you touch. For one, consistent whitespace formatting makes it easier to read the code, which I would think would help you read it and understand it faster. Second, I don't want my name to show up on a source file that is wack, and if it does, I'd rather the mistakes be mine. Third, and most important, we will avoid spending hours discussing what the rules are, and maybe persuade more folks to actually contribute. As it stands, I spent more hours discussing whitespace than I spent writing a module (a module used to test and use the changes to the config.c code). Yet, there is still no word on simple little issues. Although the indent program is probably unsafe, since it cannot guarantee that the second and third, etc. passes of code through the program would remain unchanged, the fact is, the command line switches point out that most formatting can be easily specified. And since we are human, not machine, we will likely be able to do this a little more simply than indent. Beyond whitespace, Jim has put in a few words about the structure of a file. This is very helpful, but the main impediment to getting new contributors to actually commit their code is to bring all the code up to a written standard. Written standards can only communicate so much, but code which everyone agrees meets the standard is crucial to explaining the standard. Right now, I would say, not a single file can be named which meets this test. Fortunately, as Jim has pointed out, the code is in good shape beyond the whitespace confusion. The result of a written standard with a conforming codebase will be cleaner code contributed by future developers, and much simpler process of helping new developers fix their contributions. You would be able to point to the specific problem, and to similar code elsewhere. Of course, with good examples, this would be needed even less, so those reviewing commits or patches would have an easier job. It would also focus discussion on features and implimentations, and away from mundane issues. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
