Comment by Zelphyr

Because if you comment out the code you don't benefit any more from the compiler checking that the inner block is still legal, or from your IDE to do the refactoring operations you want. The code would bit rot much faster in a comment (or removed from the code base altogether).

The thing I really can't understand is why you would compare a boolean condition to `true` instead of checking the condition itself (in other words, writing `false` instead of `true == false`). Also, let me suggest to use `&&`, not `||`. And while we're at that, I would actually write:

    if (false && my_var == 'some value') { ... }

just in case operator `==` can have side effects or relevant computational cost in your language.

Just to clarify, what do you mean "instead of commenting out the code"? The above is equivalent to

  if (my_var == 'some value') { ... }

which is not the same as commenting it out entirely.

Why even comment out? We have version control for a reason

I have used constructs like this in debugging / exploration phases (especially in languages without good debuggers, when print debugging is unavoidable or just faster). I'd be horribly embarrassed if they got committed. But... the snippet you posted isn't equivalent to a comment; `x or false` is equivalent to `x`. So it's actually equivalent to a commented-out short-circuit

    if (my_var == 'some value' || true == false) { ... } //if (my_var == 'some value') { ... }

    if (my_var == 'some value' || true == true) { ... } //if (true) { ... }

    if (my_var == 'some value' && true == false) { ... } //if (false) { ... }

That said... I would never use the comparisons `true == true` and `true == false`... that's just silly

That's not equivalent to commenting out the code block, it's just equivalent to

  if (my_var == 'some value') { ... }