All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Matheus Tavares <matheus.bernardino@usp.br>
Cc: git@vger.kernel.org, "René Scharfe" <l.s.r@web.de>,
	"Jeff King" <peff@peff.net>
Subject: Re: [PATCH 2/2] dir: improve naming of oid_stat fields in two structs
Date: Sun, 15 Mar 2020 23:17:02 -0700	[thread overview]
Message-ID: <xmqq1rpsako1.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <6fee28469e49d501e5184162bc820350f60cc3de.1584329834.git.matheus.bernardino@usp.br> (Matheus Tavares's message of "Mon, 16 Mar 2020 00:47:27 -0300")

Matheus Tavares <matheus.bernardino@usp.br> writes:

> Note: I choosed to use "st_*", as naming, for simplicity, and to keep
> the code lines small. But should we use a more verbose "oidst_*" format,
> instead, to avoid confusions with "struct stat"?
> ...
> @@ -334,8 +334,8 @@ struct dir_struct {
>  
>  	/* Enable untracked file cache if set */
>  	struct untracked_cache *untracked;
> -	struct oid_stat ss_info_exclude;
> -	struct oid_stat ss_excludes_file;
> +	struct oid_stat st_info_exclude;
> +	struct oid_stat st_excludes_file;
>  	unsigned unmanaged_exclude_files;
>  };

I tend to agree with you that using prefix "st_" for anything other
than "struct stat" proper would be confusing.  If "ss" used to stand
for "sha1 stat", I would expect "oid stat" to abbreviate to "os", at
least.

I also am wondering if we can do without any prefix, i.e. just call
them "info_exclude" and "excludes_file", because the field names are
private to each struct and there is no strong reason to have a
common prefix among fields in a single struct.  Rather, it is more
important for the fields of the same type in a single struct to have
distinct names so that the reader can easily tell them apart and the
reason for their use is straight-forward to understand, and the two
names without any prefix convey their distinction pretty well, I
would think.

It is not like we adopt a convention to name our variables with
abbreviated typenames embedded in the variable names.  We shouldn't
be doing that for field names, either, but it smells that the "give
them prefix ss_ because they are of type sha1_stat" pretty much has
origin in such school.

Thanks.

  reply	other threads:[~2020-03-16  6:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-16  3:47 [PATCH 0/2] dir: update outdated fields and comments about oid_stat Matheus Tavares
2020-03-16  3:47 ` [PATCH 1/2] dir: fix outdated comment on add_patterns() Matheus Tavares
2020-03-16  3:47 ` [PATCH 2/2] dir: improve naming of oid_stat fields in two structs Matheus Tavares
2020-03-16  6:17   ` Junio C Hamano [this message]
2020-03-16 12:31     ` Patryk Obara
2020-03-16 17:22     ` Matheus Tavares Bernardino
2020-03-16 18:31       ` Junio C Hamano
2020-03-16 18:35         ` Junio C Hamano
2020-03-16 19:20           ` Jeff King
2020-03-17 18:57 ` [PATCH v2 0/3] dir: update outdated field names and comments about oid_stat Matheus Tavares
2020-03-17 18:57   ` [PATCH v2 1/3] dir: fix outdated comment on add_patterns() Matheus Tavares
2020-03-17 18:57   ` [PATCH v2 2/3] dir: improve naming of oid_stat fields in two structs Matheus Tavares
2020-03-17 18:57   ` [PATCH v2 3/3] dir: update outdated comments about untracked cache Matheus Tavares

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=xmqq1rpsako1.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --cc=matheus.bernardino@usp.br \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.