From: Karthik Nayak <karthik.188@gmail.com>
To: karthik.188@gmail.com
Cc: git@vger.kernel.org, ps@pks.im, me@ttaylorr.com,
kristofferhaugsbakk@fastmail.com, jltobler@gmail.com
Subject: [PATCH v3] CodingGuidelines: discourage arbitrary suffixes in function names
Date: Thu, 24 Oct 2024 12:53:57 +0200 [thread overview]
Message-ID: <20241024105357.2605168-1-karthik.188@gmail.com> (raw)
In-Reply-To: <https://lore.kernel.org/r/20241021124145.636561-1-karthik.188@gmail.com>
We often name functions with arbitrary suffixes like `_1` as an
extension of another existing function. This creates confusion and
doesn't provide good clarity into the functions purpose. Let's document
good function naming etiquette in our CodingGuidelines.
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
---
I decided to send in a third version based on the feedback received from
Justin and Junio, this version is bit less aggressive and more hopeful.
Documentation/CodingGuidelines | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 30fda4142c..87904791cb 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -621,6 +621,20 @@ For C programs:
- `S_free()` releases a structure's contents and frees the
structure.
+ - Function names should be clear and descriptive, accurately reflecting
+ their purpose or behavior. Arbitrary suffixes that do not add meaningful
+ context can lead to confusion, particularly for newcomers to the codebase.
+
+ Historically, the '_1' suffix has been used in situations where:
+
+ - A function handles one element among a group that requires similar
+ processing.
+ - A recursive function has been separated from its setup phase.
+
+ The '_1' suffix can be used as a concise way to indicate these specific
+ cases. However, it is recommended to find a more descriptive name wherever
+ possible to improve the readability and maintainability of the code.
+
For Perl programs:
- Most of the C guidelines above apply.
Range-diff against v2:
1: dd556a8029 ! 1: 617b8831d3 CodingGuidelines: discourage arbitrary suffixes in function names
@@ Documentation/CodingGuidelines: 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.
++ - Function names should be clear and descriptive, accurately reflecting
++ their purpose or behavior. Arbitrary suffixes that do not add meaningful
++ context can lead to confusion, particularly for newcomers to the codebase.
+
-+ The '_1' suffix for function names has historically indicated:
++ Historically, the '_1' suffix has been used in situations where:
+
-+ - functions processing one of several elements that all need to be
-+ handled similarly.
++ - A function handles one element among a group that requires similar
++ processing.
++ - A recursive function has been separated from its setup phase.
+
-+ - recursive functions that need to be separated from a setup stage.
-+
-+ To maintain clarity and avoid confusion, such arbitrary suffixes are
-+ discouraged, as they provide no meaningful insight into the function's
-+ role.
-+
-+To maintain clarity and avoid confusion,
-+ arbitrary suffixes such as _1 are discouraged, as they provide no
-+ meaningful insight into the function's role.
++ The '_1' suffix can be used as a concise way to indicate these specific
++ cases. However, it is recommended to find a more descriptive name wherever
++ possible to improve the readability and maintainability of the code.
+
For Perl programs:
--
2.47.0
next parent reply other threads:[~2024-10-24 10:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <https://lore.kernel.org/r/20241021124145.636561-1-karthik.188@gmail.com>
2024-10-24 10:53 ` Karthik Nayak [this message]
2024-10-24 11:02 ` [PATCH v3] CodingGuidelines: discourage arbitrary suffixes in function names karthik nayak
2024-10-24 16:50 ` Taylor Blau
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=20241024105357.2605168-1-karthik.188@gmail.com \
--to=karthik.188@gmail.com \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=me@ttaylorr.com \
--cc=ps@pks.im \
/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.