this post was submitted on 03 Jul 2025
101 points (95.5% liked)

Programming

21400 readers
165 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
 

Thoughts? It does feel like there's a lot of things you can do in comments that would be impossible or impractical to do in names alone, even outside of using comments as documentation. There's certainly much more information that you can comfortably fit into a comment compared to a name.

One of the comments in the Lobste.rs post that I got this from stuck out to me in particular:

Funny story: the other day I found an old zip among my backups that contained the source code of game that I wrote 23 years ago. I was just learning to code at the time. For some reason that I forgot, I decided to comment almost every single line of that game. There are comments everywhere, even for the most obvious things. Later on, I learned that an excess of comments is actually not considered a good practice. I learned that comments might be a code smell indicating that the code is not very clear. Good code should be so clear, that it doesn’t need comments. So I started to do my best to write clear code and I mostly stopped writing comments. Doing so only for the very few parts that were cryptic or hacky or had a very weird reason for being there.

But then I found this old code full of comments. And I thought it was wonderful. It was so easy to read, so easy to understand. Then I contrasted this with my current hobby project, which I write on an off. I had abandoned it for quite some months and I was struggling to understand my own code. I’ve done my best to write clear code, but I wish I had written more comments.

And this is even worse at work, where I have to spend a ton of time reading code that others wrote. I’m sure the authors did their best to write clear code, but I often find myself scratching my head. I cherish the moment when I find some piece of code with comments explaining things. Why they did certain things, how their high level algorithm works, what does this variable do, why I’m not supposed to make that change that looks like it will simplify things but it will break a corner case.

So, I’m starting to think that this idea that comments are not such a good practice is actually quite bad. I don’t think I can remember ever reading some code and thinking “argh so many comments! so noisy” But, on the other hand, I do find myself often in the situation where I don’t understand things and I wish there were some more comments. Now I’m trying to write comments more liberally, and I think you should do the same.

I guess that’s a generalization of the op’s idea.

you are viewing a single comment's thread
view the rest of the comments
[–] ulterno@programming.dev 3 points 3 days ago (8 children)

One big reason for requiring comments being updates the same time as what is commented. I once managed to do that for a while when I alone was making and maintaining a project.

It becomes harder, the more people are working on a project and the larger the project gets.

But the alternative would lead to Java-like function-etc names and that is not very desirable either.

[–] towerful@programming.dev 8 points 3 days ago* (last edited 3 days ago) (7 children)

I feel like variable or function names that become overly verbose indicate that a specific type or a separate class should be considered.
I see it as a mild code smell.

Something like int intervalSeconds = 5 could maybe have a type that extends an int called seconds. So then you are declaring seconds Interval = 5.
It describes the unit, so the variable name just describes the purpose.
You could even add methods for fromMinutes etc. to reduce a bunch of (obvious) magic numbers elsewhere.

To extend this contrived example further, perhaps there are a couple of intervals. A refresh, a timeout and a sleep interval.
Instead of having.

int sleepIntervalSeconds = 0;
// etc...

You could create an intervals class/object/whatever.
So then you have.

public class Intervals {
    public seconds Sleep
    public seconds Refresh
    public seconds Timeout
}

The class/object defines the context, the type defines the unit, and you get nice variable names describing the purpose.

[–] thingsiplay@beehaw.org 10 points 3 days ago (2 children)

But this can lead to over engineering simple stuff. Which makes the code harder to read and maintain and more error prone. Especially if you don't need all the other stuff for the class. Worse, if you define a class then you also tend to add more stuff you don't use, just in case it might be useful.

A simple variable name is sometimes the better solution. But it depends on the situation off course. Sometimes a new class make things more clear, as it abstracts some complexity away. Yeah, we need to find a balance and that is different for every program.

[–] TehPers@beehaw.org 3 points 2 days ago

This depends. Many languages support 1 liner aliases, whether that's using/typedef in C++, type in Rust, Python, and TS, etc.

In other languages, it may be more difficult and not worth it, though this particular example should just use a duration type instead.

load more comments (1 replies)
load more comments (5 replies)
load more comments (5 replies)