linux-kernel - Re: CodingStyle question: multiple statements on a single line

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <adaskshvzw6.fsf@cisco.com>
Date:	Wed, 03 Sep 2008 11:38:01 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	Mike Isely <isely@...ox.com>
Cc:	Hans Verkuil <hverkuil@...all.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	v4l-dvb maintainer list <v4l-dvb-maintainer@...uxtv.org>
Subject: Re: CodingStyle question: multiple statements on a single line

 > <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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/