You are viewing paulmck

Previous Entry | Next Entry

elephant, penguin
Each community, proprietary or otherwise, has its own coding style, and the Linux kernel community is famously no different. The Linux kernel community's style differs in a number of ways from that of my earlier proprietary community, with perhaps the most jarring difference being the prohibition against #ifdef outside of header files. But when in Rome, it is wise to do as the Romans do, so I played along.

Fast forward a year or two, and I was writing a smallish experimental project (my first abortive attempt at a user-level RCU implementation, if you must know). So I coded the project twice, once using #ifdef freely and again adhering to the Linux kernel community's prohibitions. The second version was so much simpler that I stuck with it.

Of course, the reason that confining #ifdef to header files works so well is that it forces you to create meaningful APIs that provide higher-level abstractions. Without these abstractions, you might well have #ifdef in the middle of functions, in the middle of parameter declarations, or even in the middle of statements. Code that makes use of good higher-level abstractions will have much better structure and will therefore be much easier to debug, maintain, and extend.

Other elements of the Linux kernel community's coding style are taking longer to fully appreciate. I still have a very hard time omitting the braces around a single-statement body of an if or while statement, though I suppose that omitting the braces does shorten the code a bit, which might well make it easier to read. It is certainly the case that Linux kernel code is read much more frequently than it is written, so that would be the right way to optimize.

It is quite possible that some elements of the Linux kernel community's coding style are arbitrary, or perhaps even slightly counterproductive. If so, it is nonetheless standing the test of time quite well. And besides, when in Rome, it is wise to do as the Romans do!