Most of the points raised in the post are quite awful.
If you don’t write code that can be read, then you should learn. Don’t use comments as a crutch as that will fail.
You can have ‘sections’ titled with comments, but your code should be structured-enough to not need them.
Author, date, license, copyright: These things do not belong into the code. Author info belongs to the AUTHORS -file and git. Date comes from ctime&git. License belongs to the LICENSE -file. Copyright is implied.
All rules fly out of the window with esolangs.
Appeal to authority. Very convincing.
Generating documentation out of your comments is an ugly and terrible way to do documentation.
TODO is indeed great way to use comments. Though hilariously often you notice that the TODO can be just removed because there was a better way to do the same thing, or the thing in TODO didn’t matter after all.
The things that the code doesn’t tell, or things that are hard to gather from the code should go into the comments.
When I think something is even slightly surprising later on, I write a comment to describe why it’s there and what it’s needed for. That has turned out to be useful because it allows you to resume on the code much faster than otherwise.
If you don’t write code that can be read, then you should learn. Don’t use comments as a crutch as that will fail.
A nice ideal, but why insist that code take on the job of conveying the full semantic intent of the algorithm it’s implementing? Including natural language comments can separate the concern of semantic communication from the concern of accurate and clear implementation.
I do not think that I did insist anything like that.
Readability is about the ability to understand the written code. There is no emphasis that you’d tell anything more than what the code would inherently tell.
Most of the points raised in the post are quite awful.
The things that the code doesn’t tell, or things that are hard to gather from the code should go into the comments.
When I think something is even slightly surprising later on, I write a comment to describe why it’s there and what it’s needed for. That has turned out to be useful because it allows you to resume on the code much faster than otherwise.
To me this reads like recommendations for internal corporate code shops.
A nice ideal, but why insist that code take on the job of conveying the full semantic intent of the algorithm it’s implementing? Including natural language comments can separate the concern of semantic communication from the concern of accurate and clear implementation.
I do not think that I did insist anything like that.
Readability is about the ability to understand the written code. There is no emphasis that you’d tell anything more than what the code would inherently tell.