Messages in this thread | | | From | Roland Dreier <> | Subject | Re: CodingStyle question: multiple statements on a single line | Date | Wed, 03 Sep 2008 11:38:01 -0700 |
| |
> <quote> > Don't put multiple statements on a single line unless you have > something to hide: > </quote> > > Then what does "unless you have something to hide" refer to exactly?
I think it's a tongue-in-cheek way of saying "unless you're trying to make your code hard to read." In other words, don't do it.
> So by that reasoning "if (a) b;" - provided it stays under 80 columns - > should be even better. It occupies less space so that more code can fit > on the screen.
But it is visually hard to distinguish between the condition (a) and the statement (b) that follows it. And the arbitrary kernel rule is that we don't use that style.
> > And uniformity counts for a lot: most coding style rules are completely > > arbitrary, but having a uniform kernel style makes reading kernel code > > much easier.
> What about drivers? The statement has been made by others that there is > a strong desire for outside drivers to be brought into mainline rather > than being out-of-tree. So must every chunk of code brought in this way > be sanitized to this level of detail? In many cases that can be a large > (and some might say arbitrary) hurdle.
Of course having a uniform coding style is important for drivers too. There are many cases where someone other than the original author is debugging a driver and needs to read and understand the code, or where someone is updating all in-tree drivers to cope with an API change and must read and correctly change lots of driver code.
In general we are pretty lenient about driver code, as long as it pretty much looks like kernel code. But really, how much work is it to make a one-time sweep over a driver and change
if (a) { b; }
to
if (a) b;
especially when you have an automated tool (checkpatch.pl) that can help you find the places that would change?
> That's great. How does one reconcile this statement with subsystem > maintainers who treat checkpatch.pl - which is the epitome of > "mechanical rule" and has no notion of common sense - as the gatekeeper > for all incoming changesets?
I don't know of any such maintainers. In general if someone submitted a patch that only triggered a few checkpatch warnings and gave a rationale about why the remaining warnings shouldn't be worried about, then that would be fine with me.
- R.
| |