Let’s face it, such comments usually cause more problems than do good. If someone changes the code and forgets to modify the comment, the reader might favor one or another at random. “Stop sign” example isn’t the best but you get my point.
Comments at best should explain some non-obvious logic, or some sort of reasons for implementing one way or another. For SDKs and packages overall, public APIs should also be commented. The rest imo should be readable from code.
If someone changes the code and forgets to modify the comment, the reader might favor one or another at random.
Hence why you should comment why, not how/what.
// slow down traffic before crossing busy main road
Now you can change the stop sign to a yield without touching the comment. Or judge that the comment can be removed if it’s clear the main road does no longer exist.
I mean… you gotta have them start the habit somehow
Let’s face it, such comments usually cause more problems than do good. If someone changes the code and forgets to modify the comment, the reader might favor one or another at random. “Stop sign” example isn’t the best but you get my point.
Comments at best should explain some non-obvious logic, or some sort of reasons for implementing one way or another. For SDKs and packages overall, public APIs should also be commented. The rest imo should be readable from code.
Hence why you should comment why, not how/what.
// slow down traffic before crossing busy main road
Now you can change the stop sign to a yield without touching the comment. Or judge that the comment can be removed if it’s clear the main road does no longer exist.
I do neither, yes I do comment, but don’t apply it to easy code.
The thing is I also make easy comments about hard stuff in the code, it’s like giving a cancerous puppy a reason to live :D