From: Michael Haggerty <mhagger@alum.mit.edu>
To: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>
Cc: Stefan Beller <sbeller@google.com>, git@vger.kernel.org
Subject: Re: [PATCH v2 12/12] refs: move the remaining ref module declarations to refs.h
Date: Sat, 20 Jun 2015 03:53:13 +0200 [thread overview]
Message-ID: <5584C789.7020209@alum.mit.edu> (raw)
In-Reply-To: <20150615183504.GB4041@peff.net>
On 06/15/2015 08:35 PM, Jeff King wrote:
> On Mon, Jun 15, 2015 at 11:13:22AM -0700, Junio C Hamano wrote:
>
>>> @@ -78,15 +170,15 @@ typedef int each_ref_fn(const char *refname,
>>> * modifies the reference also returns a nonzero value to immediately
>>> * stop the iteration.
>>> */
>>> -extern int head_ref(each_ref_fn, void *);
>>> +extern int head_ref(each_ref_fn fn, void *cb_data);
>>
>> For example, between these two, what did we gain?
>>
>> Because of their types, it already was clear what the two parameters
>> are in the original, without noisewords like "fn" (which obviously
>> stands for a "function", but that is clear due to "each_ref_fn").
>
> I think the real benefit of naming parameters is that you can talk about
> "fn" and "cb_data" by name in the docstring[1]. Of course we do not do
> that here, so we could clearly wait until "if-and-when" we do so. But I
> do not think it is a big deal for our style guide to say "we always name
> parameters in declarations", and to bring things in line there (though
> perhaps it should be a separate patch in that case).
I also like the idea that all parameters in declarations should be
named. It is true that sometimes the purpose of a parameter is easy to
guess from its type without a name. But giving them names make them
easier to talk about in docstrings, in commit messages, or even on the
mailing list when reviewing patches or discussing bugs.
Moreover, I don't see the value of wasting mental energy wondering
"hmmm, in this case is the meaning sufficiently obvious from the type?"
every time I write a function declaration. It is easier to have a
consistent policy of putting them in.
Finally, when I'm inventing new functions (which I admit isn't the case
here), I usually write the declaration first and then copy-paste it to
the C file as the first step in writing the definition. If I name the
parameters in the declaration then (a) I don't have to go back and edit
them at the definition and (b) if parameter names are needed later at
the declaration (e.g., for a docstring), I don't have to edit the
declaration again, cross-referencing back to the C file to make sure I
name them consistently.
I will split the "add names in declarations" changes into a separate
patch. Also, that way Junio can ignore the patch if he still disagrees :-)
>>> -extern int for_each_glob_ref_in(each_ref_fn, const char *pattern, const char* prefix, void *);
>>> +extern int for_each_glob_ref_in(each_ref_fn fn, const char *pattern, const char* prefix, void *cb_data);
>>
>> Likewise for addition of fn and cb_data.
>>
>> If you really want to make unrelated changes to this file, what you
>> should fix is to update "const char* prefix" to "const char *prefix"
>> ;-)
>
> IMHO they are in the same boat (style fixes), and I would be happy to
> see both improved. :)
I will fix this too.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
next prev parent reply other threads:[~2015-06-20 1:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-13 14:42 [PATCH v2 00/12] Improve "refs" module encapsulation Michael Haggerty
2015-06-13 14:42 ` [PATCH v2 01/12] delete_ref(): move declaration to refs.h Michael Haggerty
2015-06-13 14:42 ` [PATCH v2 02/12] remove_branches(): remove temporary Michael Haggerty
2015-06-13 14:42 ` [PATCH v2 03/12] delete_ref(): handle special case more explicitly Michael Haggerty
2015-06-15 18:22 ` Junio C Hamano
2015-06-13 14:42 ` [PATCH v2 04/12] delete_refs(): new function for the refs API Michael Haggerty
2015-06-13 14:42 ` [PATCH v2 05/12] delete_refs(): improve error message Michael Haggerty
2015-06-15 18:29 ` Junio C Hamano
2015-06-19 14:20 ` Michael Haggerty
2015-06-13 14:42 ` [PATCH v2 06/12] prune_remote(): use delete_refs() Michael Haggerty
2015-06-15 18:35 ` Junio C Hamano
2015-06-15 18:39 ` Jeff King
2015-06-15 19:45 ` Junio C Hamano
2015-06-13 14:42 ` [PATCH v2 07/12] repack_without_refs(): make function private Michael Haggerty
2015-06-13 14:42 ` [PATCH v2 08/12] initial_ref_transaction_commit(): function for initial ref creation Michael Haggerty
2015-06-15 18:04 ` Junio C Hamano
2015-06-15 18:39 ` Junio C Hamano
2015-06-15 18:57 ` Jeff King
2015-06-15 18:53 ` Junio C Hamano
2015-06-20 2:15 ` Michael Haggerty
2015-06-13 14:42 ` [PATCH v2 09/12] refs: remove some functions from the module's public interface Michael Haggerty
2015-06-13 14:42 ` [PATCH v2 10/12] initial_ref_transaction_commit(): check for duplicate refs Michael Haggerty
2015-06-13 14:42 ` [PATCH v2 11/12] initial_ref_transaction_commit(): check for ref D/F conflicts Michael Haggerty
2015-06-13 14:42 ` [PATCH v2 12/12] refs: move the remaining ref module declarations to refs.h Michael Haggerty
2015-06-15 18:13 ` Junio C Hamano
2015-06-15 18:35 ` Jeff King
2015-06-15 19:48 ` Junio C Hamano
2015-06-20 1:53 ` Michael Haggerty [this message]
2015-06-20 3:30 ` Junio C Hamano
2015-06-15 5:20 ` [PATCH v2 00/12] Improve "refs" module encapsulation Stefan Beller
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=5584C789.7020209@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sbeller@google.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.