linux-kernel - Re: [PATCH 01/13] nvdimm: Use more typical whitespace

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] [day] [month] [year] [list]

Date:   Mon, 16 Sep 2019 00:07:55 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Vishal Verma <vishal.l.verma@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Keith Busch <keith.busch@...el.com>,
        Ira Weiny <ira.weiny@...el.com>,
        Oliver O'Halloran <oohall@...il.com>,
        linux-kernel@...r.kernel.org,
        Dan Carpenter <dan.carpenter@...cle.com>,
        linux-nvdimm@...ts.01.org
Subject: Re: [PATCH 01/13] nvdimm: Use more typical whitespace

On Thu, Sep 12, 2019 at 08:01:45AM -0700, Joe Perches wrote:
> On Thu, 2019-09-12 at 05:17 -0700, Christoph Hellwig wrote:
> > Instead of arguing what is better just stick to what the surrounding
> > code does.
> 
> That's not always feasible nor readable.
> 
> Especially for the logic inversion blocks where
> the existing code does unreadable and error prone
> things like hiding semicolons immediately after
> comments.
> 
> 	if (foo)
> 		/* longish comment */;
> 	else {
> 		<code>;
> 	}

Which has nothing to do with your patch.

> > Or in other words:  Feel free to be a codingstyle nazi for your code
> > (I am for some of mine), but leave others peoples code alone with
> > "cleanup" patches.
> 
> My point was to avoid documenting per-subsystem
> coding style rules.

It is called common sense.  In many cases different parts of the
subsystem might have slight variations.  Just stick to your
preferred style in the bounds of coding style.  Maintainers will
either remind you if they feel strongly that they have a slightly
different preference or just fix it up.  What we really don't need
need it whitespace cleanup patches in the micro variation area.