git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Abhradeep Chakraborty via GitGitGadget <gitgitgadget@gmail.com>
Cc: "Git List" <git@vger.kernel.org>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Julia Lawall" <julia.lawall@inria.fr>,
	"Abhradeep Chakraborty" <chakrabortyabhradeep79@gmail.com>
Subject: Re: [PATCH v2] add usage-strings check and amend remaining usage strings
Date: Tue, 22 Feb 2022 12:16:33 -0500	[thread overview]
Message-ID: <CAPig+cRq7H2bnkcU-V5uiWA9z=FLvxj3ji0bhO3DMX9HfptHtQ@mail.gmail.com> (raw)
In-Reply-To: <pull.1147.v2.git.1645545507689.gitgitgadget@gmail.com>

On Tue, Feb 22, 2022 at 11:27 AM Abhradeep Chakraborty via
GitGitGadget <gitgitgadget@gmail.com> wrote:
> Usage strings for git (sub)command flags has a style guide that
> suggests - first letter should not capitalized (unless requied)

s/requied/required/

> and it should skip full-stop at the end of line. But there are
> some files where usage-strings do not follow the above mentioned
> guide. Moreover, there are no checks to verify if all usage strings
> are following the guide/convention or not.
>
> Amend the usage strings that don't follow the convention/guide and
> add a check in the `parse_options_check()` function in `parse-options.c`
> to check the usage strings against the style guide.

This is a relatively minor observation, but it might make sense to
split this into two patches, the first of which fixes the offending
usage strings, and the second which adds the check to parse-options.c
to prevent more offending strings from entering the project in the
future. Anyhow, not necessarily worth a reroll.

> Signed-off-by: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
> ---
> diff --git a/parse-options.c b/parse-options.c
> @@ -492,6 +492,15 @@ static void parse_options_check(const struct option *opts)
> +               if (opts->type != OPTION_GROUP && opts->help &&
> +                       !(starts_with(opts->help, "HEAD") ||
> +                         starts_with(opts->help, "GPG") ||
> +                         starts_with(opts->help, "DEPRECATED") ||
> +                         starts_with(opts->help, "SHA1")) &&
> +                         (opts->help[0] >= 65 && opts->help[0] <= 90))
> +                       err |= optbug(opts, xstrfmt("help should not start with capital letter unless needed: %s", opts->help));

This list of hardcoded exceptions may become a maintenance burden. I
can figure out why OPTION_GROUP is treated specially here, but why use
magic numbers 65 and 90 rather than a more obvious function like
isupper()?

Perhaps instead of hardcoding an exception list and magic numbers, we
can use a simple heuristic instead. For instance, if the first two
characters of the help string are uppercase, then assume it is an
acronym (i.e. "GPG") or special name (i.e. "HEAD"), thus allowed.
Maybe something like this:

    if (opts->type != OPTION_GROUP && opts->help &&
        opts->help[0] && isupper(opts->help[0]) &&
        !(opts->help[1] && isupper(opts->help[1])))

> +               if (opts->help && !ends_with(opts->help, "...") && ends_with(opts->help, "."))
> +                       err |= optbug(opts, xstrfmt("help should not end with a dot: %s", opts->help));

  reply	other threads:[~2022-02-22 17:16 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-16 17:02 [PATCH] add usage-strings ci check and amend remaining usage strings Abhradeep Chakraborty via GitGitGadget
2022-02-21 14:51 ` Abhradeep Chakraborty
2022-02-21 15:39 ` Ævar Arnfjörð Bjarmason
2022-02-21 17:15   ` Junio C Hamano
2022-02-21 17:33   ` Abhradeep Chakraborty
2022-02-21 18:52     ` Ævar Arnfjörð Bjarmason
2022-02-22 10:57     ` Johannes Schindelin
2022-02-22 12:37       ` Ævar Arnfjörð Bjarmason
2022-02-22 13:42         ` [cocci] " Julia Lawall
2022-02-22 14:03           ` Abhradeep Chakraborty
2022-02-22 15:47           ` Abhradeep Chakraborty
2022-02-25 15:30             ` Johannes Schindelin
2022-02-25 16:16               ` Ævar Arnfjörð Bjarmason
2022-02-26  4:22                 ` Abhradeep Chakraborty
2022-02-26  8:55                   ` Julia Lawall
2022-02-25 15:03           ` [cocci] " Johannes Schindelin
2022-02-25 15:36             ` Julia Lawall
2022-02-25 16:28             ` Ævar Arnfjörð Bjarmason
2022-02-22 10:25   ` Abhradeep Chakraborty
2022-02-22 15:58 ` [PATCH v2] add usage-strings " Abhradeep Chakraborty via GitGitGadget
2022-02-22 17:16   ` Eric Sunshine [this message]
2022-02-23 11:59     ` Abhradeep Chakraborty
2022-02-23 21:17     ` Junio C Hamano
2022-02-23 21:20       ` Eric Sunshine
2022-02-24  6:26       ` Abhradeep Chakraborty
2022-02-23 14:27   ` [PATCH v3 0/2] add usage-strings ci " Abhradeep Chakraborty via GitGitGadget
2022-02-23 14:27     ` [PATCH v3 1/2] amend remaining usage strings according to style guide Abhra303 via GitGitGadget
2022-02-23 14:27     ` [PATCH v3 2/2] parse-options.c: add style checks for usage-strings Abhradeep Chakraborty via GitGitGadget
2022-02-25  5:23     ` [PATCH v4 0/2] add usage-strings ci check and amend remaining usage strings Abhradeep Chakraborty via GitGitGadget
2022-02-25  5:23       ` [PATCH v4 1/2] amend remaining usage strings according to style guide Abhradeep Chakraborty via GitGitGadget
2022-02-25  5:23       ` [PATCH v4 2/2] parse-options.c: add style checks for usage-strings Abhradeep Chakraborty via GitGitGadget
2022-02-25  6:13         ` Junio C Hamano
2022-02-25  8:08           ` Abhradeep Chakraborty
2022-02-25 17:06             ` Junio C Hamano
2022-02-26  3:57               ` Abhradeep Chakraborty
2022-02-25 15:36         ` Johannes Schindelin
2022-02-25 16:01           ` Abhradeep Chakraborty
2022-02-26  1:36           ` Junio C Hamano
2022-02-26  6:08             ` Junio C Hamano
2022-02-26  6:57               ` Abhradeep Chakraborty
2022-02-27 19:15                 ` Junio C Hamano
2022-02-28  7:39                   ` Abhradeep Chakraborty
2022-02-28 17:48                     ` Junio C Hamano
2022-02-28 19:32                       ` Ævar Arnfjörð Bjarmason
2022-03-01  6:38                       ` Abhradeep Chakraborty
2022-03-01 11:12                         ` Junio C Hamano
2022-03-01 19:37                       ` Johannes Schindelin
2022-03-03 17:34                         ` Abhradeep Chakraborty
2022-03-03 22:30                           ` Junio C Hamano
2022-03-04 14:21                             ` Abhradeep Chakraborty
2022-03-07 16:12                               ` Johannes Schindelin
2022-03-08  5:44                                 ` Abhradeep Chakraborty
2022-03-01 20:08                       ` [PATCH] parse-options: make parse_options_check() test-only Junio C Hamano
2022-03-01 21:57                         ` Ævar Arnfjörð Bjarmason
2022-03-01 22:18                           ` Junio C Hamano
2022-03-02 10:52                             ` Ævar Arnfjörð Bjarmason
2022-03-02 18:59                               ` Junio C Hamano
2022-03-02 19:17                                 ` Ævar Arnfjörð Bjarmason

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPig+cRq7H2bnkcU-V5uiWA9z=FLvxj3ji0bhO3DMX9HfptHtQ@mail.gmail.com' \
    --to=sunshine@sunshineco.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=chakrabortyabhradeep79@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=julia.lawall@inria.fr \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).