linux-kernel - Re: mfd: asic3: One function call less in asic3_irq

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 8 Jul 2019 16:38:45 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Markus Elfring <Markus.Elfring@....de>,
        kernel-janitors@...r.kernel.org
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Lee Jones <lee.jones@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: mfd: asic3: One function call less in asic3_irq_probe()

On 08.07.19 13:50, Markus Elfring wrote:
>>> I suggest to reduce a bit of duplicate source code also at this place.
>>
>> Duplicate code (logic) or just characters ?
> 
> Both.

You could also complexity for the human reader. That's a point where
personal perception comes in, which needs to be taken into account.

> The code text size can influence this aspect in considerable ways.

It *can*, but not necessarily. I'd prefer leaving this choice to the
maintainer, as he's the one who finally needs to care about all the
code. Discussions about such choices tend to be pointless (personal
perception / taste isn't something that can be debated by argument) and
risks annoying people and waste precious brain time.

> I suggest occasionally again to reconsider consequences around a principle
> like “Don't repeat yourself”.

In general correct. But in some cases repeating a few words can make the
code actually easier to read (psychologic phenomenon - human brains work
very different from computers). This needs to be carefully weighted.

Theorettically, we could do this conversation with much less words,
using some purely logic language, similar to math formulas - but for
most people this hard to do. Therefore, let's make the code easy for
us humans and let the machines (eg. compiler) do the heavy lifting.

>> But that doesn't mean that a particular patch can be accepted
>> or not in the greater context.
> 
> Would you like to find the corresponding change acceptance out at all?

For particular change, I wouldn't really object, but I don't like it
so much either. Some your other changes IMHO do make the code prettier.

>> - it's not a technical
> 
> I got an other impression.

That's the point. Psychology / personal perception plays a big role
here. We can't deduce it by pure logic.

--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287