The obvious problem is that comments have different semantics: They are used for additional information -- this is what Javadoc or Python's embedded documentation is for. Note that Javadoc (or Doxygen) solves this problem with another syntax:
This convention is understood by many syntax highlighters.
However, regular comments are frequently used to "comment out" code snippets while working on code. I assume "graying out" follows the "commenting out" idiom.
The colouring preferences of visual diff's are a completely different topic. IMHO, red/green is just a widespread convention. Of course it mentally supports the bad/good association, which is seldomly correct (even in other contexts as code).
I've come around to the idea that you should never comment out code, you should use #if #endif. And if the code has been replaced then you should include the new and old code as follows.
// comment that explains what the change was and why we are keeping the old code around.
// Date we made this change.
#if true
new code
#else
old code
#endif
That's a good idea, but it requires the language ecosystem to be shipped with that kind of preprocessor. In the given examples (Java and Python), that's not the case. And the proposal fails if you comment out non-compiling code without the context switch to a preprocessor:
if false:
this(does not compile)
else:
that.might("be")
However, regular comments are frequently used to "comment out" code snippets while working on code. I assume "graying out" follows the "commenting out" idiom.
The colouring preferences of visual diff's are a completely different topic. IMHO, red/green is just a widespread convention. Of course it mentally supports the bad/good association, which is seldomly correct (even in other contexts as code).