To K&R or not

Aneurin Price wine at shadovald.dyndns.org
Fri Jun 2 19:16:11 CDT 2006


> That said, I don't care what people do, I can read both...
> In my perfect world though, my SCM client would convert source code to
> my preferred format on checkout, and to whatever universal format the
> repository uses on checkin.  Ho hum...
> 
> 

(Personally I hate K&R because I want to be able to see the braces line 
up vertically, else I find it hard to read. Of course, that's an aside 
since, not being a Wine developer, it's a little pointless saying my 
opinion; I just happen to like doing so anyway :P)

Anyway, the point:

How about setting a standard that will be used in the repository, and 
providing the indent commands to set it that way, then indenting *every 
file* in the repository to that standard. Then every developer can use 
indent or whatever equivalent they prefer when they checkout, if they 
don't like the chosen style. By specifying a standard used by the 
repository it means that submitters can reformat their patches at 
submission time to avoid vast amounts of no-op changes caused by 
different formatting styles. This could be done automatically via an 
aliased `cvs diff` command, or whatever.

Alternatively each patch could be considered by a script (which really 
wouldn't have to be at all complex) which tries applying it, reformats 
it appropriately, generates a more appropriate patch, then unapplies it. 
This would make the process transparent to most developers, with the 
cost of more processing needing to be done at submission time - perhaps 
that would be unacceptable; I've no idea what kind of resources are 
available compared to what it would take.

Okay, I don't really expect this suggestion to be taken seriously since 
it involves modifying every file in the repository once, and potentially 
every patch, but I seriously think that it's an issue worth considering. 
Does anybody else think that it would be a feature that might really be 
used if it were implemented in <SCM of choice>?



More information about the wine-devel mailing list