4 ms·

Honestly, I would add this whole comment to the list of "absolute truths" juniors unlearn as they get more experience. And I would also point to the original p

Honestly, I would add this whole comment to the list of "absolute truths" juniors unlearn as they get more experience. And I would also point to the original post's point that types of experience matter - just because you're early 30s doesn't necessary mean you've had the right experience. If you still believe this, then - to be brutally honest - I would question the quality of the teams you've worked with. Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld. If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it. And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. A good comment explaining why something was done a particular way, or what the code was intended to accomplish, can save hours of walking up and down call stacks. It's also something that cannot be communicated through unit tests, or even integration tests, a lot of the time. Those communicate the "what" and the "how" - not the "why".

lmm 7y ago
> If you still believe this, then - to be brutally honest - I would question the quality of the team's you've worked with. To be equally brutally honest: right back at you. I would trust the quality of those I've worked with over those who believe in comments, any day of the week. My point was simply that I started as a believer in comments when I was more junior, and became anti-comment through experience. So even if we believe senior people are more likely to be right than junior people (which I very much doubt, frankly), that tells us little about whether comments are good or not. > If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. Human programmers have a limited discipline budget, and if you're spending it on keeping the comments up to date then you're not spending it on other things. Yes, you can use manual effort to keep code explanations up to date, just as you can use manual effort to ensure that you don't use memory after it's freed, or that your code is formatted consistently, or that the tests were run before a PR is merged. But you're better off automating those things and saving your manual effort for the things that can't be automated. > And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. Disagree; code can be much more precise and clear than English, that's its great advantage. As the saying goes, the code is for humans to understand, and only incidentally for the computer to execute. The whole point of coding declaratively is that the "why" is front and center and the "what"/"how" follows from that.
- mannykannot 7y ago
  > code can be much more precise and clear than English. [my emphasis.] As a common feature of most higher-level languages is that they co-opt natural language terms (and also mathematical notation, which is an option in commenting) with the intent to increase clarity, can you show us an example where code is more clear than natural language in explaining both what it is doing and why? If you are working in something like APL, I can see there might be a case... I am not so much interested in the precision issue, as both code and language can be very precisely wrong or right.
- gamblor956 7y ago
  code can be much more precise and clear than English Agreed, code is much more precise than English. But precision is not the same thing as being meaningful and without context, precision is useless. Code generally sucks at context, which is why every programming language worth its salt has comments.
- aardshark 7y ago
  I don't understand what sort of environment you work in where you don't encounter situations where comments could add clarity to the code. Do you never see code that has global side effects? Or that is written a particular way to take advantage of the hardware that it is running on? Or any other of the many ways that the intention and meaning of a piece of code within the codebase it exists in can be not immediately obvious?
  - ohaideredevs 7y ago
    >Do you never see code that has global side effects? The answer for modern languages and frameworks is "write pure functions." >Or that is written a particular way to take advantage of the hardware that it is running on? Move to service/helper/utility class for that particular hardware or with a name that clarifies it's for that particular hardware. I find comments to be necessary very rarely. Atm looking at a codebase where they are made to cover up for a lack of desire to think.
- esoterica 7y ago
kelnos 7y ago
> Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld. These are things that are often completely outside your control. > If you set a culture... At most shops, you don't get to set the culture. About the only time you do is if you're a founder or early developer. Otherwise you have to fit into the existing culture, or attempt to find a company that better reflects what you want. Sure, it's not hopeless; you can likely influence to some extent, but your influence is usually limited. > And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. I do agree with this. Any code that can't be written in a self-documenting way absolutely must be commented. However, if you find the need to do this often, it might be a sign that you should focus more on code clarity and less on (likely premature) optimization, or perhaps consider if you're really using the right tool (language, framework, etc.) for the job at hand. I will admit that I probably comment less than I should, but I feel like the average is way too verbose, and that enough comments are out of date and incorrect (often in very subtle ways) that it adds significantly to my overhead when trying to understand someone else's (or even my own) code.
kurtisc 7y ago
>If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it. They can. Just after correcting all the buffer overflows and before fixing all the use-after-frees. Then the comments can be consumed by all the other teams with the discipline and culture to avoid writing bugs for all time.

lmm 7y ago

> If you still believe this, then - to be brutally honest - I would question the quality of the team's you've worked with. To be equally brutally honest: right back at you. I would trust the quality of those I've worked with over those who believe in comments, any day of the week. My point was simply that I started as a believer in comments when I was more junior, and became anti-comment through experience. So even if we believe senior people are more likely to be right than junior people (which I very much doubt, frankly), that tells us little about whether comments are good or not. > If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. Human programmers have a limited discipline budget, and if you're spending it on keeping the comments up to date then you're not spending it on other things. Yes, you can use manual effort to keep code explanations up to date, just as you can use manual effort to ensure that you don't use memory after it's freed, or that your code is formatted consistently, or that the tests were run before a PR is merged. But you're better off automating those things and saving your manual effort for the things that can't be automated. > And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. Disagree; code can be much more precise and clear than English, that's its great advantage. As the saying goes, the code is for humans to understand, and only incidentally for the computer to execute. The whole point of coding declaratively is that the "why" is front and center and the "what"/"how" follows from that.

mannykannot 7y ago
> code can be much more precise and clear than English. [my emphasis.] As a common feature of most higher-level languages is that they co-opt natural language terms (and also mathematical notation, which is an option in commenting) with the intent to increase clarity, can you show us an example where code is more clear than natural language in explaining both what it is doing and why? If you are working in something like APL, I can see there might be a case... I am not so much interested in the precision issue, as both code and language can be very precisely wrong or right.
gamblor956 7y ago
code can be much more precise and clear than English Agreed, code is much more precise than English. But precision is not the same thing as being meaningful and without context, precision is useless. Code generally sucks at context, which is why every programming language worth its salt has comments.
aardshark 7y ago
I don't understand what sort of environment you work in where you don't encounter situations where comments could add clarity to the code. Do you never see code that has global side effects? Or that is written a particular way to take advantage of the hardware that it is running on? Or any other of the many ways that the intention and meaning of a piece of code within the codebase it exists in can be not immediately obvious?
- ohaideredevs 7y ago
  >Do you never see code that has global side effects? The answer for modern languages and frameworks is "write pure functions." >Or that is written a particular way to take advantage of the hardware that it is running on? Move to service/helper/utility class for that particular hardware or with a name that clarifies it's for that particular hardware. I find comments to be necessary very rarely. Atm looking at a codebase where they are made to cover up for a lack of desire to think.
esoterica 7y ago

kelnos 7y ago

> Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld. These are things that are often completely outside your control. > If you set a culture... At most shops, you don't get to set the culture. About the only time you do is if you're a founder or early developer. Otherwise you have to fit into the existing culture, or attempt to find a company that better reflects what you want. Sure, it's not hopeless; you can likely influence to some extent, but your influence is usually limited. > And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. I do agree with this. Any code that can't be written in a self-documenting way absolutely must be commented. However, if you find the need to do this often, it might be a sign that you should focus more on code clarity and less on (likely premature) optimization, or perhaps consider if you're really using the right tool (language, framework, etc.) for the job at hand. I will admit that I probably comment less than I should, but I feel like the average is way too verbose, and that enough comments are out of date and incorrect (often in very subtle ways) that it adds significantly to my overhead when trying to understand someone else's (or even my own) code.

kurtisc 7y ago

>If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it. They can. Just after correcting all the buffer overflows and before fixing all the use-after-frees. Then the comments can be consumed by all the other teams with the discipline and culture to avoid writing bugs for all time.