linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Jacopo Mondi <jacopo@jmondi.org>
Cc: Joe Perches <joe@perches.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-media@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Sakari Ailus <sakari.ailus@iki.fi>
Subject: Re: [PATCH v6 2/2] Driver for ON Semi AR0521 camera sensor
Date: Wed, 29 Dec 2021 16:05:11 +0100	[thread overview]
Message-ID: <m3pmpffo48.fsf@t19.piap.pl> (raw)
In-Reply-To: <20211224092226.vmqkmybpx4zodezt@uno.localdomain> (Jacopo Mondi's message of "Fri, 24 Dec 2021 10:22:26 +0100")

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

  parent reply	other threads:[~2021-12-29 15:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-23  6:54 [PATCH v6 0/2] On Semi AR0521 sensor driver Krzysztof Hałasa
2021-12-23  6:57 ` [PATCH v6 1/2] dt-binding: media: document ON Semi AR0521 sensor bindings Krzysztof Hałasa
2021-12-23  7:06 ` [PATCH v6 2/2] Driver for ON Semi AR0521 camera sensor Krzysztof Hałasa
2021-12-23 17:49   ` Joe Perches
2021-12-23 18:48     ` Jacopo Mondi
2021-12-23 19:19       ` Joe Perches
2021-12-23 20:13       ` Joe Perches
2021-12-23 20:27         ` Joe Perches
2021-12-24  9:22         ` Jacopo Mondi
2021-12-24 12:30           ` Joe Perches
2021-12-29 15:05           ` Krzysztof Hałasa [this message]
2021-12-29 14:11     ` Krzysztof Hałasa
2021-12-31 23:14   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3pmpffo48.fsf@t19.piap.pl \
    --to=khalasa@piap.pl \
    --cc=devicetree@vger.kernel.org \
    --cc=jacopo@jmondi.org \
    --cc=joe@perches.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).