git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v2] CodingGuidelines: discourage arbitrary suffixes in function names

From
Karthik Nayak <karthik.188@gmail.com>
Date
Oct 23, 2024, 07:57 UTC
Message-ID
<20241023075706.1393147-1-karthik.188@gmail.com>
In-Reply-To
<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>
---
 Documentation/CodingGuidelines | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 30fda4142c..635d6f3a27 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -621,6 +621,24 @@ 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.
+
+   The '_1' suffix for function names has historically indicated:
+
+    - functions processing one of several elements that all need to be
+      handled similarly.
+
+    - 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.
+
 For Perl programs:
 
  - Most of the C guidelines above apply.

Range-diff against v1:
1:  0acdf6902c ! 1:  dd556a8029 CodingGuidelines: discourage arbitrary suffixes in function names
    @@ Commit message
         CodingGuidelines: discourage arbitrary suffixes in function names
     
         We often name functions with arbitrary suffixes like `_1` as an
    -    extension of another existing function. This created confusion and
    +    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.
     
    @@ Documentation/CodingGuidelines: For C programs:
            structure.
      
     + - Function names should be self-explanatory, clearly reflecting their
    -+   purpose or behavior. To maintain clarity and avoid confusion,
    ++   purpose or behavior.
    ++
    ++   The '_1' suffix for function names has historically indicated:
    ++
    ++    - functions processing one of several elements that all need to be
    ++      handled similarly.
    ++
    ++    - 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.
     +
-- 
2.47.0
Previous: karthik nayakNext: Taylor Blau
Message 12 of 15 in “CodingGuidelines: discourage arbitrary suffixes in function names”
  1. CodingGuidelines: discourage arbitrary suffixes in function namesKarthik Nayak, Oct 21, 2024
  2. Patrick SteinhardtOct 21, 2024
  3. Taylor BlauOct 21, 2024
  4. karthik nayakOct 22, 2024
  5. Taylor BlauOct 22, 2024
  6. karthik nayakOct 23, 2024
  7. Junio C HamanoOct 24, 2024
  8. Taylor BlauOct 24, 2024
  9. karthik nayakOct 22, 2024
  10. Kristoffer HaugsbakkOct 21, 2024
  11. karthik nayakOct 22, 2024
  12. CodingGuidelines: discourage arbitrary suffixes in function namesKarthik Nayak, Oct 23, 2024
  13. Taylor BlauOct 23, 2024
  14. Karthik NayakOct 23, 2024
  15. Justin ToblerOct 23, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.