Depends on what it is and how complex it is. Depends on how explicit the variables and functions can be named. Depends on whether the thing I want to express is a how or a why or a how to use. Depends on if it's a public API or an internal helper used in one place with an unambiguous name. Depends on whether the audience are first year CS students, 50 year old business majors, senior developers with years of experience, or all of the above.

Always do X, never do Y rules are rarely helpful.

Does the comment here really help with your understanding of the code? If you're just now being exposed to programming then it's not enough detail, if you've been programming for 20 years it's far too much noise.

    // Assigns the value of the expression 4 + 5 to x
    // where 4 and 5 are integer literals
    // and + represents the mathematical process known as addition.
    // This allows us to later refer to x by name, where it will be replaced by the value defined here.
    x = 4 + 5;

Without getting too spicy here: What I was saying is that comments allow for people to provide "plain English" context to their code by giving a summary of what the code does, something that most contracts don't do. I was trying to point out that the example OP was using is a flawed comparison.

Code comments are typically written for whoever they're written for. I understand that"Plain English" might be a 2 sentence summary, a line by line review of each step, or a 3 letter reference to a common phrase, but it doesn't change that you have a tool available to you to provide summary context for potentially confusing or complicated pieces of logic.

I was also making the joke that if you're writing extremely complex pieces of code and not providing some kind of comment to accompany it in a setting in which that code, you're probably doing it wrong.

Some people should do some things some of the time, and other things never, but not always. Things can include writing comments for code. fixt