git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] CodingGuidelines: discourage arbitrary suffixes in function names
Date: Mon, 21 Oct 2024 14:59:00 +0200	[thread overview]
Message-ID: <ZxZP01C-9RngukZy@pks.im> (raw)
In-Reply-To: <20241021124145.636561-1-karthik.188@gmail.com>

On Mon, Oct 21, 2024 at 02:41:45PM +0200, Karthik Nayak wrote:
> We often name functions with arbitrary suffixes like `_1` as an
> extension of another existing function. This created confusion and

Micro-nit: s/created/creates/

[snip]
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 30fda4142c..b8e2d30567 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -621,6 +621,11 @@ For C programs:
>      - `S_free()` releases a structure's contents and frees the
>        structure.
>  
> + - Function names should be self-explanatory, clearly reflecting their
> +   purpose or behavior. To maintain clarity and avoid confusion,
> +   arbitrary suffixes such as _1 are discouraged, as they provide no
> +   meaningful insight into the function's role.

Names being self-explanatory is certainly a worthwhile goal, even though
I guess that it's a bit more on the idealized side of things. Functions
will often not be fully self-explanatory, which is likely just a matter
of reality. I mostly just don't want us to end on the other side of the
spectrum where we go militant on "Every function must be no longer than
2 lines of code such that it can be self-explanatory".

And yes, I'm of course stretching what you are saying quite a bit, I
know that this is not what you want to say. I'm merely writing down my
own thoughts while thinking it through.

So, that being said, I agree that we shouldn't use arbitrary suffixes,
as these are quite hard to understand indeed and typically don't really
provide any context. So as long as we interpret this rule leniently I'm
happy with it.

Patrick

  reply	other threads:[~2024-10-21 12:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-21 12:41 [PATCH] CodingGuidelines: discourage arbitrary suffixes in function names Karthik Nayak
2024-10-21 12:59 ` Patrick Steinhardt [this message]
2024-10-21 20:02   ` Taylor Blau
2024-10-22  8:45     ` karthik nayak
2024-10-22 16:41       ` Taylor Blau
2024-10-23  7:44         ` karthik nayak
2024-10-24  0:50         ` Junio C Hamano
2024-10-24 16:50           ` Taylor Blau
2024-10-22  8:34   ` karthik nayak
2024-10-21 16:51 ` Kristoffer Haugsbakk
2024-10-22  8:47   ` karthik nayak
2024-10-23  7:57 ` [PATCH v2] " Karthik Nayak
2024-10-23 20:34   ` Taylor Blau
2024-10-23 21:03     ` Karthik Nayak
2024-10-23 23:07     ` Justin Tobler

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=ZxZP01C-9RngukZy@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    /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).