Re: [PATCH] GSoC Change multiple if-else statements to be table-driven

[Junio C Hamano <gitster@pobox.com>]

Eric Sunshine <sunshine@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 <zhaox383@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.