public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org,
Cc: Patrick Steinhardt <ps@pks.im>
Subject: [PATCH v2] CodingGuidelines: document NEEDSWORK comments
Date: Thu, 12 Feb 2026 13:22:56 -0800	[thread overview]
Message-ID: <xmqqldgxmzbj.fsf@gitster.g> (raw)
In-Reply-To: <xmqqms1ft7il.fsf@gitster.g> (Junio C. Hamano's message of "Wed, 11 Feb 2026 11:17:06 -0800")

We often say things like /* NEEDSWORK: further _do_ _this_ */ in
comments, but it is a short-hand to say "We might later want to do
this.  We might not.  We do not have to decide it right now at this
moment in the commit this comment was added.  If somebody is
inclined to work in this area further, the first thing they need to
do is to figure out if it truly makes sense to do so, before blindly
doing it.

This seems to have never been documented.  Do so now.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * reworded with a bit more stress on the possibility that the
   rationale behind NEEDSWORK comment may have gotten stale.

 Documentation/CodingGuidelines | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index df72fe0177..318829d4e4 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -33,6 +33,16 @@ Git in general, a few rough rules are:
    achieve and why the changes were necessary (more on this in the
    accompanying SubmittingPatches document).
 
+ - A label "NEEDSWORK:" followed by description of the things to be
+   done is a way to leave in-code comments to document design
+   decisions yet to be made. 80% of the work to resolve a NEEDSWORK
+   comment is to decide if it still makes sense to do so, since the
+   situation around the codebase may have changed since the comment
+   was written.  It can be a very valid change to remove an existing
+   NEEDSWORK comment without doing anything else, with the commit log
+   message describing a good argument why it does not make sense to do
+   the thing the NEEDSWORK comment mentioned.
+
 Make your code readable and sensible, and don't try to be clever.
 
 As for more concrete guidelines, just imitate the existing code

Interdiff against v1:
  diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
  index b358d6bfb8..318829d4e4 100644
  --- a/Documentation/CodingGuidelines
  +++ b/Documentation/CodingGuidelines
  @@ -36,11 +36,12 @@ Git in general, a few rough rules are:
    - A label "NEEDSWORK:" followed by description of the things to be
      done is a way to leave in-code comments to document design
      decisions yet to be made. 80% of the work to resolve a NEEDSWORK
  -   comment is to decide if it makes sense to do so.  It can be a very
  -   valid change to remove an existing NEEDSWORK comment without doing
  -   anything else, with the commit log message describing a good
  -   argument why it does not make sense to do the thing the NEEDSWORK
  -   comment mentioned.
  +   comment is to decide if it still makes sense to do so, since the
  +   situation around the codebase may have changed since the comment
  +   was written.  It can be a very valid change to remove an existing
  +   NEEDSWORK comment without doing anything else, with the commit log
  +   message describing a good argument why it does not make sense to do
  +   the thing the NEEDSWORK comment mentioned.
   
   Make your code readable and sensible, and don't try to be clever.
   
-- 
2.53.0-248-g282ed54c8f



  parent reply	other threads:[~2026-02-12 21:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-11 19:17 [PATCH] CodingGuidelines: document NEEDSWORK comments Junio C Hamano
2026-02-12  7:10 ` Patrick Steinhardt
2026-02-12 15:35   ` Junio C Hamano
2026-02-12 21:22 ` Junio C Hamano [this message]
2026-02-12 22:22   ` [PATCH v2] " D. Ben Knoble
2026-02-12 22:33     ` Junio C Hamano
2026-02-14 10:19   ` Oswald Buddenhagen
2026-02-14 15:36     ` Junio C Hamano

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=xmqqldgxmzbj.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox