[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3pmpffo48.fsf@t19.piap.pl>
Date: Wed, 29 Dec 2021 16:05:11 +0100
From: Krzysztof Hałasa <khalasa@...p.pl>
To: Jacopo Mondi <jacopo@...ndi.org>
Cc: Joe Perches <joe@...ches.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Sakari Ailus <sakari.ailus@....fi>
Subject: Re: [PATCH v6 2/2] Driver for ON Semi AR0521 camera sensor
Being that "stubborn developer"...
I think all those always increasing restrictions are a dead end and
serve no useful purpose.
I strongly oppose restrictions which are just for the sake of
uniformity. I think the coding style rules make sense only as long as
they increase readability, and should never extend further. And in
particular, we should NEVER sacrifice readability for uniformity.
Unfortunately one can't measure readability easily, and what's better
for one, is worse for another (think - vision problems).
Yes, some arbitrary basic rules like tab size and brace style are
needed, and there are certain rules needed for correctness (like
"type* ptr" vs "type *ptr" which is quite visible in "type* a, b")
but the rest should serve the readability. I.e., we shouldn't want to
have all code identical - we should want it to be good.
E.g., for me, it's better to have 99 worse source files (like wildly
formatted to 80 columns) and 1 (perhaps simply more recent) file with
a better, cleaner formatting than to have 100 of the former kind.
But what do I know...
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
Powered by blists - more mailing lists