git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Dragos Foianu <dragos.foianu@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH] branch.c: simplify chain of if statements
Date: Mon, 17 Mar 2014 04:46:55 -0400	[thread overview]
Message-ID: <CAPig+cTodcfSVmHZeHuAj2kuE_CxuZqZuaNHv33hrhDmQuSmuA@mail.gmail.com> (raw)
In-Reply-To: <1395004962-18200-1-git-send-email-dragos.foianu@gmail.com>

Thanks for the submission. Comments below to give you a taste of the
Git review process...

On Sun, Mar 16, 2014 at 5:22 PM, Dragos Foianu <dragos.foianu@gmail.com> wrote:
> This patch uses a table-driven approach in order to make the code
> cleaner.

In fact, this change is not table-driven (emphasis on *driven*). It
merely moves the strings into a table, but all the logic is still in
the code. To be table-driven, the logic would be encoded in the table
as well, and that logic would *drive* the code.

This is not to say that the code must be table-driven. The GSoC
microproject merely asks if doing so would make sense. Whether it
would is for you to decide, and then to explain to reviewers the
reason(s) why you did or did not make it so.

> Although not necessary, it helps code reability by not
> forcing the user to read the print message when trying to
> understand what the code does.

The if-chain is just sufficiently complex that the print messages may
actually help the reader understand the logic of the code, so this
argument seems specious.

> The rebase check has been moved to
> the verbose if statement to avoid making the same check in each of
> the four if statements.
>
> Signed-off-by: Dragos Foianu <dragos.foianu@gmail.com>
> ---

Overall, the patch appears to be properly constructed and you seem to
have digested Documentation/SubmittingPatches. Good.

>  branch.c | 32 ++++++++++++++++----------------
>  1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/branch.c b/branch.c
> index 723a36b..e2fe455 100644
> --- a/branch.c
> +++ b/branch.c
> @@ -54,6 +54,14 @@ void install_branch_config(int flag, const char *local, const char *origin, cons
>         struct strbuf key = STRBUF_INIT;
>         int rebasing = should_setup_rebase(origin);
>
> +       const char *verbose_prints[4] = {

No need to hard-code 4. 'const char *verbose_prints[]' is sufficient.

On this project, it is preferred (though not consistent) to name
arrays using singular form, such as verbose_print[], so that accessing
a single element, such as verbose_print[42], reads more grammatically
correct.

verbose_prints[] is not as descriptive as it could be. Perhaps
something like verbose_messages[] would be more informative (though
awfully long; maybe just messages[]).

> +               "Branch %s set up to track remote branch %s from %s%s",

Even though you are correctly accessing these strings via _() in the
printf_ln() invocation, you still need to mark them translatable here
with N_(). See section 4.7 [1] of the gettext manual.

[1]: http://www.gnu.org/software/gettext/manual/gettext.html#Special-cases

> +               "Branch %s set up to track local branch %s%s",
> +               "Branch %s set up to track remote ref %s%s",
> +               "Branch %s set up to track local ref %s%s"
> +       };
> +       char *verbose_rebasing = rebasing ? " by rebasing." : ".";

This should be 'const char *'.

Matthieu already mentioned [2] that this sort of "lego" string
construction is not internationalization-friendly. See section 4.3 [3]
of the gettext manual for details.

[2]: http://thread.gmane.org/gmane.comp.version-control.git/244210/focus=244226
[3]: http://www.gnu.org/software/gettext/manual/gettext.html#Preparing-Strings

>         if (remote_is_branch
>             && !strcmp(local, shortname)
>             && !origin) {
> @@ -78,25 +86,17 @@ void install_branch_config(int flag, const char *local, const char *origin, cons
>
>         if (flag & BRANCH_CONFIG_VERBOSE) {
>                 if (remote_is_branch && origin)
> -                       printf_ln(rebasing ?
> -                                 _("Branch %s set up to track remote branch %s from %s by rebasing.") :
> -                                 _("Branch %s set up to track remote branch %s from %s."),
> -                                 local, shortname, origin);
> +                       printf_ln(_(verbose_prints[0]),
> +                               local, shortname, origin, verbose_rebasing);
>                 else if (remote_is_branch && !origin)
> -                       printf_ln(rebasing ?
> -                                 _("Branch %s set up to track local branch %s by rebasing.") :
> -                                 _("Branch %s set up to track local branch %s."),
> -                                 local, shortname);
> +                       printf_ln(_(verbose_prints[1]),
> +                               local, shortname, verbose_rebasing);
>                 else if (!remote_is_branch && origin)
> -                       printf_ln(rebasing ?
> -                                 _("Branch %s set up to track remote ref %s by rebasing.") :
> -                                 _("Branch %s set up to track remote ref %s."),
> -                                 local, remote);
> +                       printf_ln(_(verbose_prints[2]),
> +                               local, remote, verbose_rebasing);
>                 else if (!remote_is_branch && !origin)
> -                       printf_ln(rebasing ?
> -                                 _("Branch %s set up to track local ref %s by rebasing.") :
> -                                 _("Branch %s set up to track local ref %s."),
> -                                 local, remote);
> +                       printf_ln(_(verbose_prints[3]),
> +                               local, remote, verbose_rebasing);

These hard-coded indexing constants (0, 1, 2, 3) are fragile and
convey little meaning to the reader. Try to consider how to compute
the index into verbose_prints[] based upon the values of
'remote_is_branch' and 'origin'. What are the different ways you could
do so?

>                 else
>                         die("BUG: impossible combination of %d and %p",
>                             remote_is_branch, origin);
> --
> 1.8.3.2

  parent reply	other threads:[~2014-03-17  8:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-16 21:22 [PATCH] branch.c: simplify chain of if statements Dragos Foianu
2014-03-17  7:23 ` Matthieu Moy
2014-03-17  8:08   ` Eric Sunshine
2014-03-17  8:46 ` Eric Sunshine [this message]
2014-03-17 11:46   ` Dragos Foianu
2014-03-17 12:53     ` Ævar Arnfjörð Bjarmason
2014-03-18 21:36     ` Eric Sunshine

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=CAPig+cTodcfSVmHZeHuAj2kuE_CxuZqZuaNHv33hrhDmQuSmuA@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=dragos.foianu@gmail.com \
    --cc=git@vger.kernel.org \
    /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).