git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3/5] notes: extract logic into set_display_notes()

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Dec 9, 2019, 16:26 UTC
Message-ID
<CAPig+cToM+sHj-C5N_F2F+5B3LTPLVf39_-kCSih_WkuBOV+mA@mail.gmail.com>
In-Reply-To
<62543250c4ea0e0327f974cb90b294c60b525982.1575896661.git.liu.denton@gmail.com>
On Mon, Dec 9, 2019 at 8:11 AM Denton Liu <liu.denton@gmail.com> wrote:
Show 31 quoted lines
> Instead of open coding the logic that tweaks the variables in
> `struct display_notes_opt` within handle_revision_opt(), abstract away the
> logic into set_display_notes() so that it can be reused.
>
> Signed-off-by: Denton Liu <liu.denton@gmail.com>
> ---
> diff --git a/notes.c b/notes.c
> @@ -1045,6 +1045,30 @@ void init_display_notes(struct display_notes_opt *opt)
> +int set_display_notes(struct display_notes_opt *opt, int show_notes, const char *opt_ref)
> +{
> +       if (show_notes) {
> +               if (opt_ref) {
> +                       struct strbuf buf = STRBUF_INIT;
> +                       strbuf_addstr(&buf, opt_ref);
> +                       expand_notes_ref(&buf);
> +                       string_list_append(&opt->extra_notes_refs,
> +                                          strbuf_detach(&buf, NULL));
> +               } else {
> +                       opt->use_default_notes = 1;
> +               }
> +       } else {
> +               opt->use_default_notes = -1;
> +               /* we have been strdup'ing ourselves, so trick
> +                * string_list into free()ing strings */
> +               opt->extra_notes_refs.strdup_strings = 1;
> +               string_list_clear(&opt->extra_notes_refs, 0);
> +               opt->extra_notes_refs.strdup_strings = 0;
> +       }
> +
> +       return !!show_notes;
> +}

When you find yourself creating a function in which the entire body is (effectively) a single giant 'if' statement and in which the 'then' and 'else' arms are chosen by an input argument to that function (and remaining input arguments are used only by one or the other branch), it is usually a good sign that you should really be creating two distinct functions. Doing so would reduce cognitive load of people reading and trying to understand the code (as well as reduce the indentation level). For instance, you might introduce these functions:

    void enable_display_notes(struct display_notes_opt *opt, const
char *opt_ref);
    void disable_display_notes(struct display_notes_opt *opt);
Show 11 quoted lines
> diff --git a/notes.h b/notes.h
> @@ -265,6 +265,16 @@ struct display_notes_opt {
> +/*
> + * Set a display_notes_opt to a given state. 'show_notes' is a boolean
> + * representing whether or not to show notes. 'opt_ref' points to a
> + * string for the notes ref, or is NULL if the default notes should be
> + * used.
> + *
> + * Return 'show_notes' normalized to 1 or 0.
> + */
> +int set_display_notes(struct display_notes_opt *opt, int show_notes, const char *opt_ref);

Please drop the meaningless return value. While I understand you did this as a convenience to make calling code a bit more concise, it nevertheless doesn't belong here since it conflates that convenience code with the true purpose of this function (which to enable or disable note display). Worse, it increases cognitive load on people trying to comprehend the code since it requires that they consult the documentation for set_display_notes() to understand what is going on. That is, this is far less obvious:

    revs->show_notes = set_display_notes(&revs->notes_opt, 1, optarg);
than this:
    revs->show_notes = 1;
    enable_display_notes(&revs->notes_opt, optarg);

Alternately, if revs->show_notes and revs->notes_opt really ought always be set in lockstep, then maybe it makes more sense to have the "enable" and "disable" functions accept 'revs' directly in order to be able to adjust both revs->show_notes and revs_notes_opt together:

    void enable_display_notes(struct rev_info *revs, const char *opt_ref);
    void disable_display_notes(struct rev_info *revs);
Previous: Denton LiuNext: Denton Liu
Message 5 of 11 in “format-patch: improve handling of `format.notes`”
  1. 0/5 format-patch: improve handling of `format.notes`Denton Liu, Dec 9, 2019
  2. 1/5 notes: rename to load_display_notes()Denton Liu, Dec 9, 2019
  3. 2/5 notes: create init_display_notes() helperDenton Liu, Dec 9, 2019
  4. 3/5 notes: extract logic into set_display_notes()Denton Liu, Dec 9, 2019
  5. Eric SunshineDec 9, 2019
  6. Denton LiuDec 9, 2019
  7. Philip OakleyDec 10, 2019
  8. 4/5 format-patch: use --notes behavior for format.notesDenton Liu, Dec 9, 2019
  9. 5/5 format-patch: move git_config() before repo_init_revisions()Denton Liu, Dec 9, 2019
  10. Junio C HamanoDec 9, 2019
  11. Elijah NewrenDec 9, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.