From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <junkio@cox.net>
Subject: Re: Numeric constants as strings
Date: Mon, 19 Feb 2007 11:00:37 +0000 [thread overview]
Message-ID: <200702191100.42953.andyparkins@gmail.com> (raw)
In-Reply-To: <7vbqjq8ojr.fsf@assigned-by-dhcp.cox.net>
On Monday 2007 February 19 09:49, Junio C Hamano wrote:
> I do not want to risk discouraging public discussion on this
> topic, but I am not sure if this is really worth it.
It's not primarily for that purpose, but rather to improve readability.
For example, this little bit of patch:
- if (get_sha1_hex(buffer+5, tree_sha1) || buffer[45] != '\n')
+ if (get_sha1_hex(buffer+5, tree_sha1) || buffer[HASH_WIDTH_ASCII+5] != '\n')
return objerror(&commit->object, "invalid 'tree' line format - bad sha1");
- buffer += 46;
+ buffer += HASH_WIDTH_ASCII+6;
while (!memcmp(buffer, "parent ", 7)) {
- if (get_sha1_hex(buffer+7, sha1) || buffer[47] != '\n')
+ if (get_sha1_hex(buffer+7, sha1) || buffer[HASH_WIDTH_ASCII+7] != '\n')
return objerror(&commit->object, "invalid 'parent' line format - bad sha1");
- buffer += 48;
+ buffer += HASH_WIDTH_ASCII+8;
Using HASH_WIDTH_ASCII+8 is much clearer for a reader to be able to understand
intent than 48. Especially when the variables in question are called "buffer"
it's harder to track what is being stored in the buffer without a named constant.
There are also a few other places where 20 is used and HASH_WIDTH_ASCII is not
intended.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
next prev parent reply other threads:[~2007-02-19 11:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-19 9:16 Numeric constants as strings Andy Parkins
2007-02-19 9:38 ` Junio C Hamano
2007-02-19 9:49 ` Shawn O. Pearce
2007-02-19 10:01 ` Matthieu Moy
2007-02-19 10:54 ` Andy Parkins
2007-02-19 10:14 ` Andy Parkins
2007-02-19 9:49 ` Junio C Hamano
2007-02-19 11:00 ` Andy Parkins [this message]
2007-02-19 10:04 ` Mark Wooding
2007-02-19 11:02 ` Andy Parkins
2007-02-20 13:06 ` Jakub Narebski
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=200702191100.42953.andyparkins@gmail.com \
--to=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.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).