All of lore.kernel.org
 help / color / mirror / Atom feed
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".

[...]



  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.