you might know that Deja-Vu moment when you look at a new patch that has been submitted to lkml and you have a strange, weird “feeling” that there’s something wrong about the patch.
It’s totally subconscious, and you take a closer look and a few seconds later you find a real bug in the code.
That “feeling” i believe comes from a fundamental property of how human vision is connected to the human brain: pattern matching. Really good programmers have built a “library” of patterns of “good” and “bad” looking coding practices.
If a patch or if a file has a clean _style_, bugs and deeper structural problems often stand out like a sore thumb. But if the code is peppered with random style noise, it’s a lot harder (for me at least) to notice real bugs. I can notice bugs in a squeeky clean code base about 5 times easier than in a noisy codebase. This effect alone makes checkpatch indispensible for the scheduler and for arch/x86.
I’ve yet to see a _single_ example of a good, experienced kernel programmer who writes code that looks absolutely careless and sloppy, but which is top-notch otherwise.
I’ve spent a lot of time this past year cleaning up a medium-sized codebase written in cross-platform C89 (c’mon vendors, can’t you upgrade your compilers tosupport C99 already? I know Microsoft has a few programmers on staff.). Coding standards help immensely.
Even something as simple as aligning the equals signs in assignments and separating paragraphs in code with newlines increases skimmability greatly. Ingo’s right though, and I wish I’d realized it consciously earlier. Consistent code requires much less brainpower to decipher its structure, leaving that much more brainpower to find real problems.
While there may never be a refactoring called “Beautify code block” (and technically that’s not improving the design of the code), it’s an important tool for human analysis of code.