Tanay Abhra <tanay...@gmail.com> writes:

> In record_author_date() & parse_gpg_output() ,using skip_prefix() instead of
> starts_with() is more elegant and abstracts away the details.

Avoid subjective judgement like "more elegant" when justifying your
change; you are not your own judge.

The caller of starts_with() actually can use the string that follows
the expected prefix and that is the reason why using skip_prefix()
in these places is a good idea.  There is no need to be subjective
to justify that change.

I do not think there is any more abstracting away of the details in
this change.  The updated uses a different and more suitable
abstraction than the original.

> diff --git a/commit.c b/commit.c
> index 6bf4fe0..668c703 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -548,7 +548,7 @@ define_commit_slab(author_date_slab, unsigned long);
>  static void record_author_date(struct author_date_slab *author_date,
>                              struct commit *commit)
>  {
> -     const char *buf, *line_end;
> +     const char *buf, *line_end, *skip;
>       char *buffer = NULL;
>       struct ident_split ident;
>       char *date_end;
> @@ -566,14 +566,15 @@ static void record_author_date(struct author_date_slab 
> *author_date,
>            buf;
>            buf = line_end + 1) {
>               line_end = strchrnul(buf, '\n');
> -             if (!starts_with(buf, "author ")) {
> +             if (!(skip = skip_prefix(buf, "author "))) {

We tend to avoid assignments in conditionals.

>                       if (!line_end[0] || line_end[1] == '\n')
>                               return; /* end of header */
>                       continue;
>               }
> +             buf = skip;
>               if (split_ident_line(&ident,
> -                                  buf + strlen("author "),
> -                                  line_end - (buf + strlen("author "))) ||
> +                                  buf,
> +                                  line_end - buf) ||
>                   !ident.date_begin || !ident.date_end)
>                       goto fail_exit; /* malformed "author" line */
>               break;

If you give a sensible name to what 'buf + strlen("author ")' is,
then the result becomes a lot more readable compared to the
original, and I think that is what this change is about.

And "skip" is not a good name for that.  'but + strlen("author ")'
is what split_ident_line() expects its input to be split; let's
tentatively call it "ident_line" and see what the call looks like:

        split_ident_line(&ident, ident_line, line_end - ident_line))

And that is what we want to see here.  It is a bit more clear than
the original that we are splitting the ident information on the line,
ident_line (you could call it ident_begin) points at the beginning
and line_end points at the end of that ident information.

Use of skip_prefix(), which I am sure you took the name of the new
variable "skip" from, is merely an implementation detail of finding
where the ident begins.  A good rule of thumb to remember is to name
things after what they are, not how you obtain them, how they are
used or what they are used for/as.

> @@ -1193,9 +1194,9 @@ static void parse_gpg_output(struct signature_check 
> *sigc)
>       for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
>               const char *found, *next;
>  
> -             if (starts_with(buf, sigcheck_gpg_status[i].check + 1)) {
> +             if (found = skip_prefix(buf, sigcheck_gpg_status[i].check + 1)) 
> {
>                       /* At the very beginning of the buffer */
> -                     found = buf + strlen(sigcheck_gpg_status[i].check + 1);
> +                     ;
>               } else {
>                       found = strstr(buf, sigcheck_gpg_status[i].check);
>                       if (!found)

This hunk looks good.  It can be a separate patch but they are both
minor changes so it is OK to have it in a single patch.
--
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

Reply via email to