From: Junio C Hamano <gitster@pobox.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: Elijah Newren <newren@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/3] diff-merges: cleanup func_by_opt()
Date: Fri, 16 Sep 2022 09:14:48 -0700 [thread overview]
Message-ID: <xmqqy1uji9dz.fsf@gitster.g> (raw)
In-Reply-To: <87wna3jwx8.fsf@osv.gnss.ru> (Sergey Organov's message of "Fri, 16 Sep 2022 16:01:07 +0300")
Sergey Organov <sorganov@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Sergey Organov <sorganov@gmail.com> writes:
>>
>>> Get rid of unneeded "else" statements in func_by_opt().
>>
>> While it is true that loss of "else" will not change what the code
>> means, this change feels subjective and I'd say it falls into "once
>> committed, it is not worth the patch noise to go in and change"
>> category, not a "clean-up we should do".
>
> I agree the "else" vs "no else" is subjective, but the problem in fact
> is that the first "if", unlike the rest of them, already had no "else",
> making the code inconsistent.
This is a static helper function about a single "optarg" string that
wanted to say "switch(optarg) { case "off": ... }" but couldn't in
C, and I happen to view if strcmp else if strcmp ... sequence on the
same string a poor-man's substitute for such a construct. So my
take of it is to call the second "if" not being "else if" a problem,
not the rest of it. If we add a new condition on a different input,
making it "if (x) ...; switch(optarg) { ... }" that talks about
something other than optarg, then writing it all with "if" without
"else if" would make it harder to see the pattern, but I do not care
too deeply either way, because this is unlikely to gain any logic
more involved than "switch(optarg) { ... }".
> So the fix should either be adding one
> "else" to the first "if", or remove all of the "else". I chose the
> latter, to end up with less noisy code.
Yup, see above for the reason why I would choose else-if cascade if
I had to but I do not care too deeply either way in this particular
case ;-)
next prev parent reply other threads:[~2022-09-16 16:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-14 19:30 [PATCH 0/3] diff-merges: minor cleanups Sergey Organov
2022-09-14 19:31 ` [PATCH 1/3] diff-merges: cleanup func_by_opt() Sergey Organov
2022-09-15 18:47 ` Junio C Hamano
2022-09-16 13:01 ` Sergey Organov
2022-09-16 16:14 ` Junio C Hamano [this message]
2022-09-16 16:28 ` Sergey Organov
2022-09-14 19:31 ` [PATCH 2/3] diff-merges: cleanup set_diff_merges() Sergey Organov
2022-09-15 20:41 ` Junio C Hamano
2022-09-16 13:38 ` Sergey Organov
2022-09-14 19:31 ` [PATCH 3/3] diff-merges: clarify log.diffMerges documentation Sergey Organov
2022-09-15 18:43 ` Junio C Hamano
2022-09-16 13:46 ` Sergey Organov
2022-09-16 16:21 ` Junio C Hamano
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=xmqqy1uji9dz.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--cc=sorganov@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.