From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Hans de Goede <hdegoede@redhat.com>, linux-hwmon@vger.kernel.org
Cc: "Günter Röck" <linux@roeck-us.net>,
"Jean Delvare" <jdelvare@suse.com>,
"Jonathan Cameron" <jic23@kernel.org>,
kernel-janitors@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: hwmon/sch5627: Use common error handling code in sch5627_probe()
Date: Tue, 13 Mar 2018 10:30:32 +0100 [thread overview]
Message-ID: <4e0856d8-3b2c-35f0-50a5-bfbe34615dfa@users.sourceforge.net> (raw)
In-Reply-To: <e8a45f50-b625-ccb5-88cc-b888f57d1ca1@redhat.com>
> 1 file changed, 29 insertions(+), 31 deletions(-)
>
> So you are asking people to review 60 changed lines to save 2,
A bit of object code reduction might become useful also in this case.
> that alone should be the point where you stop yourself from
> *even* sending this patch.
I proposed just another collateral evolution.
> Next time before you send a patch please carefully think if the
> saving is worth the combination of reviewers time + the risk of
> regressions (and keep in mind that both the reviewers time and
> the risk of regressions cost increase for more complex changes).
Source code transformations were integrated in other software areas
according to such a change pattern.
> As for this specific discussion, there are certain "design-patterns"
> in the kernel, goto style error handling is one of them, the pattern
> there ALWAYS is:
…
> Notice the fall-thoughs those are ALWAYS there, never, ever is
> there a goto after a cleanup label.
It seems that I present an unusual update suggestion as a software
design variant.
> Your patches black goto magic completely messes this up
You can view the proposal in such a way.
> and clearly falls under the CS101 rule: never use goto.
There might a target conflict with information from the section
“7) Centralized exiting of functions” in the document “coding-style.rst”.
Regards,
Markus
next prev parent reply other threads:[~2018-03-13 9:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-12 21:23 [PATCH] hwmon/sch5627: Use common error handling code in sch5627_probe() SF Markus Elfring
2018-03-13 8:19 ` Hans de Goede
2018-03-13 8:25 ` SF Markus Elfring
2018-03-13 8:52 ` Hans de Goede
2018-03-13 9:30 ` SF Markus Elfring [this message]
2018-03-13 16:00 ` [PATCH] " Guenter Roeck
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=4e0856d8-3b2c-35f0-50a5-bfbe34615dfa@users.sourceforge.net \
--to=elfring@users.sourceforge.net \
--cc=hdegoede@redhat.com \
--cc=jdelvare@suse.com \
--cc=jic23@kernel.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/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).