Eric Sunshine <sunsh...@sunshineco.com> writes:
> Thanks for the resubmission. Comments below.
Thanks, Eric, for helping so many micro exercises.
> On Thu, Mar 13, 2014 at 4:20 PM, Yao Zhao <zhaox...@umn.edu> wrote:
>> Subject: [PATCH] GSoC Change multiple if-else statements to be table-driven
>
> It's a good idea to let reviewers know that this is attempt 2. Do so
> by saying [PATCH v2]. Your next one will be [PATCH v3]. The -v option
> for "git format-email" can help.
Yao, I think Eric meant "git format-patch".
> When your patch is applied via "git am", text inside [...] gets
> stripped automatically. The "GSoC" tells email readers what this
> submission is about, but isn't relevant to the actual commit message.
> It should be placed inside [...]. For instance: [PATCH/GSoC v2].
So in short,
Subject: [PATCH/GSoC v2] branch.c: turn nested if-else logic to
table-driven
or something.
>> + typedef struct PRINT_LIST {
> ...
>> + int b_origin;
>> + } PRINT_LIST;
We do not do ALL_CAPS names and tend not to introduce one-off
typedefs for struct. Instead we would just use "struct print_list"
throughout (if we were to indeed use such a new struct, that is).
>> + PRINT_LIST print_list[] = {
>> + {.print_str = _("Branch %s set up to track remote branch %s
>> from %s by rebasing."),
>> + .arg2 = shortname, .arg3 = origin,
>> + .b_rebasing = 1,
>> .b_remote_is_branch = 1, .b_origin = 1},
>> I am confused here: I use struct initializer and I am not sure if it's ok
>> because it is only supported by ANSI
> ...
> Indeed, you want to avoid named field initializers in this project and
> instead use positional initializers.
Correct.
> Translatable strings in an initializer should be wrapped with N_()
> instead of _(). You will still need to use _() later on when you
> reference the string from the table. See section 4.7 [2] of the GNU
> gettext manual for details.
Correct.
> An alternate approach might be to use a multi-dimensional array,
> where the boolean values of rebasing, remote_is_branch, and origin
> are keys into the array. This would allow you to pick out the
> correct PRINT_LIST entry directly (no looping), thus eliminating
> the need for those b_rebasing, b_remote_is_branch, and b_origin
> members.
Correct.
After seeing so many "table driven" submissions, I however tend to
agree with your earlier comment on another thread on this same
micro, where you said an nested if-else cascade that was rewritten
in a clearer way (sorry, I do not remember whose submission it was
offhand) may be the best answer to the "Would it make sense to make
the code table-driven?" question, even though I tentatively queued
d7ea7894 (install_branch_config(): simplify verbose messages logic,
2014-03-13) from Paweł on 'pu'.
Thanks for a review.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
