this post was submitted on 14 Mar 2025
630 points (99.1% liked)

Programmer Humor

21487 readers
1448 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] Gumbyyy@lemmy.world 7 points 12 hours ago (1 children)
[–] Maalus@lemmy.world 4 points 12 hours ago (2 children)

The only moment you write comments is when you are doing something extremely weird for a specific reason that will not be immediately obvious and you want to warn the person doing a refactor in the future. In any other case, writing self documenting code is the way. If you are unable to do that, then your code needs to be rewrtitten.

[–] bpev@lemmy.world 3 points 3 hours ago* (last edited 3 hours ago)

Mmmm kind of? I wouldn't categorize most comments as describing "extremely weird" reasons, though. Code will generally explain the "how", while comments can describe the "why". For example, think of an enum with ViewSize "mini" and "full". It might be nice to have a comment to briefly summarize what ViewSize is meant to represent, and maybe link to a spec. Basically, a comment here will connect the intention with the implementation.

A more inline-comment example of this might be if there's a slightly nuanced case that you want to be very clear about, ala maybe a Javascript true/false/null case, where you might be checking === false, and specifically don't want someone to refactor it into a falsy check. Kind of contrived example , but that sort of thing. This is probably more the "extremely weird" comment you're talking about; almost just a warning that this might not be what you think it is.

The other common use-case I find good for comments is for summarizing the goals/purpose of a complex function. This is mostly for future people who might utilize this function, and don't want to read through a bunch of code, just to remember the nuances of what it's supposed to do. For example, a "sortEvents" function, you may want to summarize the business requirements of the sort at the top. Although, this kind of thing may be different depending on how documentation is stored.

[–] ruekk@lemm.ee 7 points 11 hours ago (2 children)

Self documenting code is a myth as what's self documenting to one person is not to the next. Code comments and process/workflow documentation is needed for a healthy codebase.

[–] jimmux@programming.dev 1 points 4 hours ago

I thought the same, until I spent a few years on a codebase where self-documenting code was enforced with detailed code reviews. That does a very good job of clearing up the ambiguity.

If you can't get that kind of review, then by all means use comments.