I have also seen well commented code, but in this article I concentrate on the bad ones. Are you saying you have never seen a bad code comment?

I think this is also in line with my article, since not being able to put yourself into somebody else’s shoes (or even in yourself future’s ones) is the reason for so much bad comments. But adding a comment to every single line cannot be the solution either, at least not in a higher programming language.

I agree with almost all of what you say, but the thing IME is that in most cases people learn to comment a lot, which results in comments that feel like they’ve been done just for the sake of it, which is one of the main problems IMO. It’s not like “just add a comment, it won’t hurt”, since comments can be immensely misleading and literally take a lot of time until figuring out that the comment was wrong if you trust the wrong ones.

I also agree that this tends to be worse with bad code, which also is not surprising. Sometimes it feels to me like people think they can fix bad code with some comments, and I think that is far from being true.

I also admit that especially the title of the article might be a bit provocative, but giving the general positive sentiment of comments I think this is called for. Sometimes you have to exaggerate a bit to get some attention. I don’t like click-baiting either, but unfortunately it works ;-)

I give you that, but I am not talking about assembly languages, therefore the examples from my blogpost aren’t showing any :-)

Totally agree, that’s why I also mentioned this in the article.

Very often good code that is self-explanatory does not need any comments at all and if it does, the comment should describe why it has been implemented this way instead of just repeating what the code already says.

Ah, you are talking about systemd, wasn’t aware of that… I imagine that to be much more complicated for many use cases. E.g. running a unit test (as I describe in the article) isn’t something I would use systemd for. Setting up a path and a service seems more complicated than using entr, and it is probably also harder to get to the output as well.

I am not exactly sure what you mean by that… But the main advantage is that the command does not have to be executed manually everytime you change something. Instead entr recognizes when something changes and re-executes the command for you.

Doesn’t it also use case and esacand a few others? Such a weird language^^

That’s true, but the syntax is different then. In this blog post I cover fish, and I didn’t intent to say that this cannot be done in other shells (and I think I never said so).