logoalt Hacker News

swe_dimatoday at 4:25 PM2 repliesview on HN

my prompt (doesn't help):

> Go easy on the comments, only add comments if there's a big gotcha that is not clear from the code itself, or if something in another place is going to cause a side effect. Code should be self-documenting. When in doubt, don't add a comment at all. If you do have to add a comment, make it short and on point. Comments should show history of code changes or functionality, only comment on the current state (or not at all).


Replies

iFiretoday at 5:58 PM

Your prompt is so similar to my prompt.

> Go easy on the comments.

> If you do have to add a comment, make it short and on point.

I defined what easy meant numerically.

<claude> Match the comment density of FoundationDB, which is 12 to 14 percent of non-blank lines in `fdbserver`, `fdbclient` and `flow` at 7.3. </claude>

> only add comments if there's a big gotcha that is not clear from the code itself

<claude> Comment why the code does a thing, not what it does. </claude>

> Comments should show history of code changes or functionality, only comment on the current state (or not at all)

I call this the tenseless continuous-present voice.

<claude> Each sentence states what is currently true of the system. </claude>

<claude> This rules out past-tense edit narration, future or imperative planning, and aging temporal qualifiers such as “now” or “previously”. </claude>

<claude> A sentence that states a present truth stays correct as long as the code stays the same, and goes stale visibly the moment the code changes. </claude>