All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Jean Delvare <khali@linux-fr.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	David Brownell <david-b@pacbell.net>
Subject: Re: [PATCH] CodingStyle: Printing numbers in parentheses is fine
Date: Sat, 29 Sep 2007 03:51:56 -0700	[thread overview]
Message-ID: <20070929035156.cd6fe860.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070929122530.5c45f743@hyperion.delvare>

On Sat, 29 Sep 2007 12:25:30 +0200 Jean Delvare <khali@linux-fr.org> wrote:

> Remove a not particularly relevant rule from CodingStyle.
> Sometimes, printing numbers in parentheses doesn't add value, but in
> some (most?) cases it makes the message easier to read. As a matter of
> fact, this practice is widely used in the kernel:
> 
> linux-2.6.23-rc8$ quilt grep -I '(%l*[du])' | wc -l
> 3166
> linux-2.6.23-rc8$
> 
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> ---
>  Documentation/CodingStyle |    2 --
>  1 file changed, 2 deletions(-)
> 
> --- linux-2.6.23-rc8.orig/Documentation/CodingStyle	2007-07-23 16:44:32.000000000 +0200
> +++ linux-2.6.23-rc8/Documentation/CodingStyle	2007-09-28 23:53:23.000000000 +0200
> @@ -638,8 +638,6 @@ concise, clear, and unambiguous.
>  
>  Kernel messages do not have to be terminated with a period.
>  
> -Printing numbers in parentheses (%d) adds no value and should be avoided.
> -
>  There are a number of driver model diagnostic macros in <linux/device.h>
>  which you should use to make sure messages are matched to the right device
>  and driver, and are tagged with the right level:  dev_err(), dev_warn(),

I wonder how that got there.

Printing something like

	bytes remaining: 0x12 (18)

is a quite logical thing to do, although pretty darm pointless.


otoh, looking at the various instances, we have lots of stuff like this:


  printk(KERN_ERR "seq-oss: unable to delete queue %d (%d)\n", queue, rc);

which I would argue is wrong and is inconsistent with most other error
reporting.  It should be

	unable to delete queue %d: %d



And this:

	printk(KERN_ERR "%s:  context size (%u) exceeds payload "

doesn't need the parens


Here:

	printk("hardirqs last  enabled at (%u): ", curr->hardirq_enable_event);
	print_ip_sym(curr->hardirq_enable_ip);
	printk("hardirqs last disabled at (%u): ", curr->hardirq_disable_event);
	print_ip_sym(curr->hardirq_disable_ip);
	printk("softirqs last  enabled at (%u): ", curr->softirq_enable_event);
	print_ip_sym(curr->softirq_enable_ip);
	printk("softirqs last disabled at (%u): ", curr->softirq_disable_event);
	print_ip_sym(curr->softirq_disable_ip);

all the parens are just illogical and should be removed.


Here:

		xlog_warn("XFS: %s: unrecognised log version (%d).",
			__FUNCTION__, INT_GET(rhead->h_version, ARCH_CONVERT));

should use "unrecognised log version: %d"


This:

		printk(KERN_ERR "udf: unknown compression code (%d) stri=%s\n",
		       cmp_id, ocu_i->u_name);

should use colon as well.


So in fact a large number of the instances I see in there are illogical and
basically gramatically wrong and should be converted to use a colon.


  reply	other threads:[~2007-09-29 10:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-29 10:25 [PATCH] CodingStyle: Printing numbers in parentheses is fine Jean Delvare
2007-09-29 10:51 ` Andrew Morton [this message]
2007-09-29 17:19   ` David Brownell
2007-09-29 18:29   ` Randy Dunlap
2007-09-29 18:53     ` David Brownell
2007-09-29 20:13       ` Randy Dunlap
2007-09-29 22:30         ` David Brownell
2007-09-29 22:51           ` Randy Dunlap
2007-09-29 22:55           ` Måns Rullgård
2007-09-30 10:28           ` Jean Delvare
2007-09-30  2:18   ` Valdis.Kletnieks
2007-09-30 10:11   ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070929035156.cd6fe860.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=david-b@pacbell.net \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.