Re: [PATCH v2] scripts/show_delta: reformat code

[Hu Haowen]

On 2023/12/1 14:49, Nicolas Schier wrote:
> On Fri, Dec 01, 2023 at 01:35:40PM +0800, Hu Haowen wrote:
> > Correct some lines in irregular coding style to make them look more
> > harmonious and fit the common coding regulations in Python.
> >
> > Signed-off-by: Hu Haowen <2023002089@xxxxxxxxxxxxxxxx>
> > ---
> >   scripts/show_delta | 18 +++++++++---------
> >   1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/scripts/show_delta b/scripts/show_delta
> > index 291ad65e3089..33446adce74b 100755
> > --- a/scripts/show_delta
> > +++ b/scripts/show_delta
> > @@ -13,7 +13,7 @@ import sys
> >   import string
> >   
> >   def usage():
> > -	print ("""usage: show_delta [<options>] <filename>
> > +	print("""usage: show_delta [<options>] <filename>
> Hi,
>
> thanks for your patch.  What Miguel already noticed for v1 is valid for
> v2, too: there are still inconsistencies in the coding style, e.g.
> `print (...)` and `print(...)`.
>
> To simplify a consistent coding style for future work on the script,
> using an external tool for reformatting (and mentioning it in the commit
> message) would be helpful.  Miguel suggested Black or Ruff, I think this
> is a good idea.


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?

(The Black code style: 
https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html)

Thanks,
Hu Haowen


> Kind regards,
> Nicolas