On 08/21/10 12:47, Blue Swirl wrote: > On Sat, Aug 21, 2010 at 9:54 AM, Markus Armbruster <arm...@redhat.com> wrote: >> Unless you mass-convert existing code to your style, tools working on >> source files won't cut it, because reports of the patch's style >> violations are prone to drown in a sea of reports of preexisting style >> violations. There's a reason why Linux's scrtips/checkpatch.pl works on >> patch files. > > Mass conversion would have the benefit that submitters, who use old > code as their reference, are more likely to use the correct style.
Problem with mass conversion is that it becomes really hard to track changes for debugging. While it would be nice to get all code to look the 'right way<tm>' in a snap, then I think it will cause more harm than good. >> I still think inventing yet another idiosyncratic coding style plus >> tools to enforce it is a waste of time. > > There are historical reasons for the style used in the current code > base. There are also reasons why CODING_STYLE was written like it > stands now. Yes, it's a classic case, there is always the historical side and personal bios for why it was written the way it is. Often this is goes back to personal preference rather than reason :( IMHO it isn't such a big issue what the style is, as long as it is consistent and efficient. The problem with the style we have now is that is is totally inconsistent and has elements making it harder to debug the code, like the braces around single line if statements. I totally agree with Markus that it seems like wasted effort to come up with new tools and having to maintain them when there are good ones out there like the ones from the Linux kernel. Cheers, Jes
