Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
MIME-Version: 1.0
References: <20231201053540.9534-1-2023002089@link.tyut.edu.cn>
 <ZWmB67THrLcztb-3@buildd.core.avm.de> <b118c12f-b94d-46aa-ab72-55ac2ce7813f@link.tyut.edu.cn>
In-Reply-To: <b118c12f-b94d-46aa-ab72-55ac2ce7813f@link.tyut.edu.cn>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Fri, 1 Dec 2023 16:32:51 +0100
Message-ID: <CANiq72krGxPJ948xp2=pEBXS==P_AKrHLYEUBc3M7482bbL9UA@mail.gmail.com>
Subject: Re: [PATCH v2] scripts/show_delta: reformat code
To:     Hu Haowen <2023002089@link.tyut.edu.cn>
Cc:     Nicolas Schier <n.schier@avm.de>, gregkh@linuxfoundation.org,
        akpm@linux-foundation.org, masahiroy@kernel.org,
        ndesaulniers@google.com, ojeda@kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Dec 1, 2023 at 3:49=E2=80=AFPM Hu Haowen <2023002089@link.tyut.edu.=
cn> wrote:
>
> Just got a glimpse on the usage of Black and realized the convenience
> it provides and strictness of code style it supplies. It is pretty
> feasible for code style analysis series of Python scripts within the
> kernel source.
>
> However, here comes the issue that this tool binds itself to its own
> bunches of rules how the code should be formatted by default, resulting
> in some kind of scenes which do not match what we want when doing kernel
> programming, or more exactly this tool may not follow the rules regulated
> by the kernel developers or mentioned within kernel documentation,
> which means we are obliged to conduct a programming standard for Python
> coding within kernel source internally, and then ask Black to review and
> reformat the code accordingly. But this programming standard is absent
> currently, consequently it should be specified initially from my
> perspective. What is your idea on this?

This is essentially the same problem we have for C.

For C, what I did was try to find an initial "common enough" style and
document the tool in `Documentation/process/clang-format.rst` so that
maintainers could start to use the tool easily if they so wished, at
their own pace. In other words, the benefit was just having the style
around. Then, maybe, after some years, when the tool is good enough
and maintainers are on board, we can start to think about
`clang-format`ing the kernel.

Now, for Python, we have orders of magnitude less code, so perhaps
using the default options of whatever tool is a possibility. In any
case, it would be a matter of exploring the tools, asking for
feedback, documenting the choice made in `Documentation/`, providing
an example patch formatting one of the existing scripts, etc. The main
benefit would be having decided on a particular approach. I would
still avoid sending tree-wide formatting of all scripts until
maintainers of those scripts agree.

I would also recommend taking the chance to also look at linting and
not just formatting, especially given tools like Ruff provide both.
And if you happen to find an actual issue in an existing script thanks
to the linting, then that would be great and allows you to showcase
their usefulness (and maintainers are probably more likely to welcome
series like that vs. just formatting :)

Hope that helps!

Cheers,
Miguel