First, if you start using comments to explain your code, you will have to maintain these as well. Guess what, this likely will not happen everytime, because people need to always keep in mind to do this whenever something in code changes.
Second, code can be self-explaining without the need to look for a certain function. Usually the naming and how you build the whole project helps a lot and maybe sometimes it is necessary to see, what other functions are called, too. But if you cannot understand it without looking for many other places in the project, maybe something different is wrong and the issue is not missing comments. These would rather patch the issues, not solve them.
I am not asking for to not comment, but usually there are only a few special cases, which actually need comments and this can be very specific to the technologies chosen.
Is it just me or feels the "mental health" and "inclusion" part again just following a trend? I would not say it is wrong (I am totally with you in sense of, that not everybody is the same and we need to respect and support each other), but I do not see, how the commenting part has to be necessarily connected to this.
You can have high quality comments and that helps a lot navigating codebases.
There's usually a lot of context behind the decisions for some routing and for code that has to be read a lot (99% of it) they help.
For enterprise apps that have been touched by lots of people (most of them already gone), comments are valuable. I've found important warnings/explanations and it's saved me hours that are spent in better ways.
Comments are async communication and expand context beyond the mere computer instructions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First, if you start using comments to explain your code, you will have to maintain these as well. Guess what, this likely will not happen everytime, because people need to always keep in mind to do this whenever something in code changes.
Second, code can be self-explaining without the need to look for a certain function. Usually the naming and how you build the whole project helps a lot and maybe sometimes it is necessary to see, what other functions are called, too. But if you cannot understand it without looking for many other places in the project, maybe something different is wrong and the issue is not missing comments. These would rather patch the issues, not solve them.
I am not asking for to not comment, but usually there are only a few special cases, which actually need comments and this can be very specific to the technologies chosen.
Is it just me or feels the "mental health" and "inclusion" part again just following a trend? I would not say it is wrong (I am totally with you in sense of, that not everybody is the same and we need to respect and support each other), but I do not see, how the commenting part has to be necessarily connected to this.
You can have high quality comments and that helps a lot navigating codebases.
There's usually a lot of context behind the decisions for some routing and for code that has to be read a lot (99% of it) they help.
For enterprise apps that have been touched by lots of people (most of them already gone), comments are valuable. I've found important warnings/explanations and it's saved me hours that are spent in better ways.
Comments are async communication and expand context beyond the mere computer instructions.