From: Paolo Bonzini <pbonzini@redhat.com>
To: Thomas Huth <thuth@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 16:22:33 +0200 [thread overview]
Message-ID: <55ED9DA9.80208@redhat.com> (raw)
In-Reply-To: <55ED8EA0.6040400@redhat.com>
On 07/09/2015 15:18, Thomas Huth wrote:
> 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.
QEMU has 2816 files.
529 files have at least one line with 81+ columns.
1342 files have at least one 77-80 columns line that would now warn.
1474 files have no lines with 77+ columns.
Some classification of line lengths (with the "BSD exception"):
Length Count
77-80 16358
78-80 11853
79-80 7852
80 2623
81+ 6588
Some other interesting data:
- However, only 605 files have 5 or more lines with 77+ columns, so the
odds of warnings after copy-n-paste are pretty slim.
- Also, of the 77+ column lines, about 10% are in macros that are
aligned right with a backslash.
- 1195 files have at least one 78-80 columns that would now warn; 979
files have at least one 79-80 columns that would now warn; 644 files
have at least one 80 columns that would now warn.
- With the above patch, the "BSD exception" hits 5471 times, of which
about 1900 are false positives. If the warning is restricted to 80+
columns, the "BSD exception" is still necessary, but it only hits 1033
times and only 152 are false positives.
Based on the above data, I suggest having 79 columns as the limit (with
the "BSD exception" unfortunately). This still makes it possible to
watch diffs on an 80-column terminal without wrapping.
Alternatively you would have 80 columns with no "BSD exception", which
is (more or less) what was in the previous submission of the patch.
> 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.
I agree it's not nice.
> 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...
It's just the default size of a terminal. If I do "<Ctrl-N> git show
<Right click> <Enter>" I get an 80-column terminal.
Paolo
ps: to find "BSD exception" false positives I used the following regex:
copy|deal|rights|included in|EXPRESS OR|OR OTHER|ARISING FROM,|at
your|or later.|by the Free|software without|THE USE OF
THIS|licenses/>.|its contributors|detailed
below.|USA.|USA|PURPOSE|CONSEQUENTIAL|STRICT
next prev parent reply other threads:[~2015-09-07 14:22 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
2015-09-07 14:22 ` Paolo Bonzini [this message]
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=55ED9DA9.80208@redhat.com \
--to=pbonzini@redhat.com \
--cc=afaerber@suse.de \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/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).