From: Michael Haggerty <mhagger@alum•mit.edu>
To: David Kastrup <dak@gnu•org>
Cc: Junio C Hamano <gitster@pobox•com>, git@vger•kernel.org
Subject: Re: [PATCH v2] cache_tree_find(): remove redundant checks
Date: Tue, 04 Mar 2014 11:22:44 +0100 [thread overview]
Message-ID: <5315A974.5000104@alum.mit.edu> (raw)
In-Reply-To: <87ppm2i9ot.fsf@fencepost.gnu.org>
On 03/04/2014 10:40 AM, David Kastrup wrote:
> Michael Haggerty <mhagger@alum•mit.edu> writes:
>
>> The beginning of the loop ensures that slash can never be NULL. So
>> don't keep checking whether it is NULL later in the loop.
>>
>> Furthermore, there is no need for an early
>>
>> return it;
>>
>> from the loop if slash points at the end of the string, because that
>> is exactly what will happen when the while condition fails at the
>> start of the next iteration.
>
> Hm. Another suggestion. You have
>
> const char *slash = strchr(path, '/');
> if (!slash)
> slash = path + strlen(path);
> [...]
> sub = find_subtree(it, path, slash - path, 0);
> [...]
> path = slash;
> while (*path == '/')
> path++;
> }
>
> At the price of introducing another variable, this could be
>
> const char *slash = strchr(path, '/');
> size_t len = slash ? slash - path : strlen(path);
> [...]
> sub = find_subtree(it, path, len, 0);
> [...]
> if (!slash)
> break;
> for (path = slash; *path == '/';)
> path++;
> }
>
> This introduces another variable and another condition. The advantage
> is that "slash" indeed points at a slash or is NULL, so the variable
> names correspond better to what happens. Alternatively, it might make
> sense to rename "slash" into "end" or "endpart" or whatever. Since
> I can't think of a pretty name, I lean towards preferring the latter
> version as it reads nicer. I prefer code to read like children's books
> rather than mystery novels.
I think we're reaching the point of diminishing returns here. I can't
muster a strong feeling either way about your suggestion to add a "len"
variable.
BTW, I purposely didn't use a "for" loop at the end (even though I
usually like them) because I wanted to keep it prominent that path is
being updated to the value of slash. Putting that assignment in a for
loop makes it easy to overlook because it puts "path" in the spot that
usually holds an inconsequential iteration variable.
YMMV.
Michael
--
Michael Haggerty
mhagger@alum•mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2014-03-04 10:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 8:31 [PATCH v2] cache_tree_find(): remove redundant checks Michael Haggerty
2014-03-04 9:40 ` David Kastrup
2014-03-04 10:22 ` Michael Haggerty [this message]
2014-03-04 10:34 ` David Kastrup
2014-03-04 21:05 ` Junio C Hamano
2014-03-04 22:24 ` Michael Haggerty
2014-03-04 23:18 ` Junio C Hamano
2014-03-05 17:57 ` Junio C Hamano
2014-03-05 4:38 ` David Kastrup
2014-03-05 18:40 ` Junio C Hamano
2014-03-04 21:11 ` [microproject idea] 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=5315A974.5000104@alum.mit.edu \
--to=mhagger@alum$(echo .)mit.edu \
--cc=dak@gnu$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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