I'm genuinely curious -- what is the thinking behind "too long to be put as code comment"? I've never heard that before.
It's not like we're conserving paper. And syntax highlighters helpfully give comments different colors so you can skip over them while reading.
Personally, I've never once wished that a particular piece of code were less commented, but there are hundreds if not thousands of times I've wished that there was more explanation, or any at all.
Comments are frequently out of date with the code that they're describing. This tendency is somewhat linear with the length if a comment and therefore longer comments will be more incorrect, more quickly. I'm not being facetious, this is a readily observed phenomena.
Long comments get out of date quickly because it isn't clear how the comments relate to the code on a quick scan. In this case, you want a quick note as to why the code is there. You can add external references if needed.
You don't want to make someone who is editing code stop to think about how it affects the comments.
> What's the point of comments then if your general rule is that it should be fine to edit code without changing the comments?
Not without changing the comments. Without stopping to ponder how two paragraphs of comments fit into the code changes. The comments (aside from API documentation) should annotate the code, not the other way around.
It's not like we're conserving paper. And syntax highlighters helpfully give comments different colors so you can skip over them while reading.
Personally, I've never once wished that a particular piece of code were less commented, but there are hundreds if not thousands of times I've wished that there was more explanation, or any at all.