Messages in this thread | | | Date | Sat, 5 Jan 2008 15:37:28 +0100 | From | Andi Kleen <> | Subject | Re: [PATCH x86] [12/16] Optimize lock prefix switching to run less frequently |
| |
> Sloppy and inconsistent code also leaves a lasting negative impression > on newbie developers. I've heard quite a few opinions about Linux's code > base being a lot less consistent (and hence harder to understand) than
Do you think they did refer to code style (as in indentation etc.) here? When I was talking to such people my impression was that their complaints usually came from other issues.
e.g. I know from talking to a few people that they consider the BSD kernels cleaner just because they have a very consistent printk style for driver probing so it looks cleaner at booting. Sounds silly (although I can sympathize a little bit) but true.
Besides the kernel indentation is not that inconsistent anyways.
> Frankly, if you dont understand the necessity of clean code, and the > negative effect that a large number of small uncleanlinesses can have on > a large system then you wont be getting the big picture either. > > checkpatch.pl is not perfect (and it cannot be), and we dont use it as a > rigid criterium (and dont want to), but it's quite conservative (its > false positive rate for code that i maintain is below 1% - which is
Rate is certainly higher here.
> sloppy patches. It gives us a way to improve the kernel's code quality > gradually. We change about 10% of the kernel codebase in every kernel > release, that is about 30% of the kernel every year. With checkpatch.pl > we'll have a very clean kernel in just a few years.
That's the problem I have with your position. You equate quality with coding style or checkpatch.pl output. I think it's only a small part of it.
If we follow your description above to the logical conclusion then we could get the perfect kernel(tm) very quickly just by running everything through Lindent or recruit a few hundred people who run all files through checkpatch.pl and fix all warnings and then we end up with the perfect kernel with "improved code quality"
Great idea! And is it ok for me to refer to that plan as "the Ingo Molnar plan" (TIMP) in the future? I'm sure a short term for it will come handy in future discussions ;-)
-Andi
| |