On Sun, 22 Aug 2010, Blue Swirl wrote: > On Sun, Aug 22, 2010 at 4:40 PM, Jes Sorensen <jes.soren...@redhat.com> wrote: > > 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. > > Well, consider for example mass braces conversion to the One Style, > whichever that is. Would it be better to do it in one commit or > multiple commits? If the latter, push all commits back-to-back or just > one at a time now and then? > > At the extreme end, we could even convert one statement per commit. > This would make bug hunting with git bisect extremely precise. There > would be a cost of long commit log. > > For the patch submitters, wouldn't one shot conversion (with one push, > one or many commits) be less painful? > > >>> 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 > > Fully agree. > > > and has elements making it harder to debug the code, like > > the braces around single line if statements. > > What's the problem?
Disregarding my own stance on the braces, braces around single statement is actually helpful w.r.t. debugging imaging trying to set a break point on said singlesttement, plain impossible in following case: if (a) b; > > > 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. > > I also find the tool argument very attractive. No other style has that > benefit. > -- mailto:av1...@comtv.ru