From: Markus Armbruster <armbru@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Denis V. Lunev" <den@openvz.org>,
qemu-devel@nongnu.org, Chao Liu <chao.liu@processmission.com>,
"Daniel P. Berrange" <berrange@redhat.com>,
Philippe Mathieu-Daude <philmd@oss.qualcomm.com>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [PATCH] checkpatch: warn about hunks which only add blank lines
Date: Thu, 06 Aug 2026 07:28:29 +0200 [thread overview]
Message-ID: <877bm3yg02.fsf@pond.sub.org> (raw)
In-Reply-To: <e8921043-2405-4b20-95f8-7cfc2d9bd8f9@redhat.com> (Thomas Huth's message of "Thu, 6 Aug 2026 06:37:34 +0200")
Thomas Huth <thuth@redhat.com> writes:
> On 31/07/2026 15.40, Denis V. Lunev wrote:
>> Patches sometimes carry a hunk whose entire content is one or two
>> added blank lines. It changes nothing, it makes the diff longer and
>> it survives review because nobody looks twice at a blank line. The
>> blank line itself is perfectly fine, the gratuitous hunk is not.
>
> Well, I wouldn't say that the blank line itself is fine. It depends.
> In source code, there normally should not be more than one empty line between code blocks, that's why I complained to the patch in your pull request.
For what it's worth, Python style *demands* two blank lines in places.
Here's what happens when I delete one of them:
$ pycodestyle scripts/qapi/parser.py
scripts/qapi/parser.py:656:1: E302 expected 2 blank lines, found 1
Why? PEP 8 "Style Guide for Python Code" section "Blank Lines":
--> Surround top-level function and class definitions with two blank
--> lines.
Method definitions inside a class are surrounded by a single blank
line.
Extra blank lines may be used (sparingly) to separate groups of
related functions. Blank lines may be omitted between a bunch of
related one-liners (e.g. a set of dummy implementations).
Use blank lines in functions, sparingly, to indicate logical
sections.
Python accepts the control-L (i.e. ^L) form feed character as
whitespace; many tools treat these characters as page separators, so
you may use them to separate pages of related sections of your
file. Note, some editors and web-based code viewers may not
recognize control-L as a form feed and will show another glyph in
its place.
We run pycodestyle via flake8 from python/tests/linters.py. Still not
part of "make check".
[...]
next prev parent reply other threads:[~2026-08-06 5:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 13:40 [PATCH] checkpatch: warn about hunks which only add blank lines Denis V. Lunev
2026-08-06 4:37 ` Thomas Huth
2026-08-06 5:28 ` Markus Armbruster [this message]
2026-08-10 19:28 ` Denis V. Lunev
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=877bm3yg02.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=chao.liu@processmission.com \
--cc=den@openvz.org \
--cc=peter.maydell@linaro.org \
--cc=philmd@oss.qualcomm.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 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.