linux-kernel - Re: [PATCH v3] checkpatch: add a rule to check general block comment style

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4e42f2580d8b473ac7e25642b039adf73b5efe06.camel@perches.com>
Date:   Mon, 19 Jul 2021 00:52:17 -0700
From:   Joe Perches <joe@...ches.com>
To:     Ani Sinha <ani@...sinha.ca>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        anirban.sinha@...ia.com, mikelley@...rosoft.com,
        Andy Whitcroft <apw@...onical.com>,
        Dwaipayan Ray <dwaipayanray1@...il.com>
Subject: Re: [PATCH v3] checkpatch: add a rule to check general block
 comment style

On Mon, 2021-07-19 at 12:25 +0530, Ani Sinha wrote:

> I do not see why we cannot add this rule to checkpatch. If the
> reviewer likes the other style of commenting they can always ask for a
> correction. Having checkpatch agree with Linus' preferred style of
> commenting and the preferred documeted style of commenting (which seems to
> be the same) does make everything uniform and agreeable.

Too many novice developers take checkpatch output as dicta.

It's not.

It's just produces suggestions that should _always_ be taken
not very seriously.  Those suggestions should perhaps be
considered, but good taste should always override a brainless
script.

_Very_ few senior developers really care that much about any
particular comment style.

These are the same senior developers that would be burdened
with unnecessary patches to review from those novice developers
that believe checkpatch should always be followed.

Do not unnecessarily burden senior developers.
They are generally have other priorities.