From: Thomas Huth <thuth@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: Markus Armbruster <armbru@redhat.com>,
Andreas Faerber <afaerber@suse.de>,
Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/4] CODING_STYLE, checkpatch: update line length rules
Date: Mon, 7 Sep 2015 15:18:24 +0200 [thread overview]
Message-ID: <55ED8EA0.6040400@redhat.com> (raw)
In-Reply-To: <1441619584-17992-3-git-send-email-pbonzini@redhat.com>
On 07/09/15 11:53, Paolo Bonzini wrote:
> Line lengths above 80 characters do exist. They are rare, but
> they happen from time to time. An ignored rule is worse than an
> exception to the rule, so do the latter.
>
> Based on remarks from the list, make the preferred line length
> slightly lower than 80 characters, to account for extra characters
> in unified diffs (including three-way diffs) and for email quoting.
>
> Checkpatch has some code to detect doc comments that doesn't apply
> to QEMU; the usual limits apply even for doc comments in our case.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> CODING_STYLE | 13 ++++++++++---
> scripts/checkpatch.pl | 21 +++++++++++++++------
> 2 files changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/CODING_STYLE b/CODING_STYLE
> index 3c6978f..34d5526 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -31,14 +31,21 @@ Do not leave whitespace dangling off the ends of lines.
>
> 2. Line width
>
> -Lines are 80 characters; not longer.
> +Lines should be 76 characters; try not to make them longer.
> +
> +Sometimes it is hard to do, especially when dealing with QEMU subsystems
> +that use long function or symbol names. Even in that case, do not make
> +lines much longer than 76 characters.
>
> Rationale:
> - Some people like to tile their 24" screens with a 6x4 matrix of 80x24
> - xterms and use vi in all of them. The best way to punish them is to
> - let them keep doing it.
> + xterms and use vi in all of them. They also examine diffs (and three-way
> + diffs) on an 80-column terminal, accounting for two extra characters.
> + The best way to punish them is to let them keep doing it.
> - Code and especially patches is much more readable if limited to a sane
> line length. Eighty is traditional.
> + - The four-space indentation makes the most common excuse ("But look
> + at all that white space on the left!") moot.
> - It is the QEMU coding style.
>
> 3. Naming
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 7f0aae9..bc32d8f 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -1466,14 +1466,23 @@ sub process {
> # check we are in a valid source file if not then ignore this hunk
> next if ($realfile !~ /\.(h|c|cpp|s|S|pl|sh)$/);
>
> -#80 column limit
> - if ($line =~ /^\+/ && $prevrawline !~ /\/\*\*/ &&
> - $rawline !~ /^.\s*\*\s*\@$Ident\s/ &&
> +#90 column limit
> + if ($line =~ /^\+/ &&
> !($line =~ /^\+\s*$logFunctions\s*\(\s*(?:(KERN_\S+\s*|[^"]*))?"[X\t]*"\s*(?:,|\)\s*;)\s*$/ ||
> - $line =~ /^\+\s*"[^"]*"\s*(?:\s*|,|\)\s*;)\s*$/) &&
> - $length > 80)
> + !($line =~ /^\+\s*"[^"]*"\s*(?:\s*|,|\)\s*;)\s*$/))
> {
> - WARN("line over 80 characters\n" . $herecurr);
> + if ($length > 90) {
> + ERROR("line over 90 characters\n" . $herecurr);
> + } elsif ($length > 76 && !($rawline =~ /^\+ \* /)) {
> + # The BSD license blurb has 80 character lines.
> + # Avoid warning on cut-and-pasted license text.
> + WARN("line over 76 characters\n" . $herecurr);
Sorry, this is _ugly_! First, the limit in QEMU has always been 80
columns in the past, thus we've got tons of code that is written with 80
columns already, so you suddenly even can not even copy-n-paste / move
around code anymore that was valid before?!? That'll be a PITA since you
have to reformat all patches that move code around - and it will also be
a PITA for all reviewers since checking whether old code matches new
code becomes more difficult.
Second, I really don't like the idea of introducing exceptions here like
it is done with the BSD license check above ... that will only cause
confusion and "let's add another exception" situations later, I think.
Can't we simply keep the 80 columns limit instead, please? IMHO people
having trouble to view patches with 80 columns should simply be forced
to switch to proper tools instead...
Thomas
next prev parent reply other threads:[~2015-09-07 13:18 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-07 9:53 [Qemu-devel] [PATCH 0/4] updates to coding style and checkpatch Paolo Bonzini
2015-09-07 9:53 ` [Qemu-devel] [PATCH 1/4] CODING_STYLE: update mixed declaration rules Paolo Bonzini
2015-09-09 9:20 ` Stefan Hajnoczi
2015-09-09 10:43 ` Alex Bennée
2015-09-07 9:53 ` [Qemu-devel] [PATCH 2/4] CODING_STYLE, checkpatch: update line length rules Paolo Bonzini
2015-09-07 13:18 ` Thomas Huth [this message]
2015-09-07 14:22 ` Paolo Bonzini
2015-09-07 14:37 ` Thomas Huth
2015-09-07 15:23 ` Markus Armbruster
2015-09-07 16:06 ` Paolo Bonzini
2015-09-07 17:05 ` Markus Armbruster
2015-09-09 16:26 ` John Snow
2015-09-09 17:22 ` Peter Maydell
2015-09-09 19:23 ` Eduardo Habkost
2015-09-09 20:28 ` Paolo Bonzini
2015-09-09 19:09 ` Eduardo Habkost
2015-09-07 17:02 ` Thomas Huth
2015-09-09 18:45 ` Eduardo Habkost
2015-09-07 15:17 ` Markus Armbruster
2015-09-07 15:54 ` Paolo Bonzini
2015-09-07 16:59 ` Markus Armbruster
2015-09-07 9:53 ` [Qemu-devel] [PATCH 3/4] checkpatch: adapt some tests to QEMU Paolo Bonzini
2015-09-09 9:22 ` Stefan Hajnoczi
2015-09-17 14:24 ` Peter Maydell
2015-09-17 16:00 ` Paolo Bonzini
2015-09-17 16:16 ` Peter Maydell
2015-09-17 16:32 ` Paolo Bonzini
2015-09-17 16:44 ` Eric Blake
2015-09-18 6:53 ` Markus Armbruster
2015-10-04 18:44 ` Peter Maydell
2015-10-05 18:11 ` Eduardo Habkost
2015-10-05 18:47 ` Peter Maydell
2015-10-05 19:27 ` Paolo Bonzini
2015-09-07 9:53 ` [Qemu-devel] [PATCH 4/4] checkpatch: remove tests that are not relevant outside the kernel Paolo Bonzini
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=55ED8EA0.6040400@redhat.com \
--to=thuth@redhat.com \
--cc=afaerber@suse.de \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).