3 ms·

That's arguably worse than commented out code.

• beagle3 14y ago
  Argue then: The editor can just as easily highlight this is "unreachable/useless code" (maybe even using the comment colors). However, the compiler will check the syntax and semantics of that statement to make sure it is ok. I say it's better then commenting out code (although a #define non_executable_for_reference_only if 0 would have probably made that more readable)
  • DanWaterworth 14y ago
    You shouldn't add code that doesn't do anything, it just creates a cognitive burden. You might be able to relieve that burden with a clever editor, but there's a clear (and useful) dividing line between code and comments that you are blurring.
    • beagle3 14y ago
      I disagree that it's code. It's documentation - that can be checked by the compiler for correctness. Yes, it is a hack, but it serves a purpose. It's just a matter of convention; It creates as much cognitive burden as documentation does. And indeed, I avoid documentation where it isn't needed, but I do put it where it is helpful - just like I do with code that doesn't need to be built/executed as part of the product, but that helps understanding.
      • stcredzero 14y ago
        > It's documentation - that can be checked by the compiler for correctness. Exactly. This was a convention used by Smalltalk shops. It came about because of the appearance of the Refactoring Browser, which caused a 10X increase in the rate and ease of refactoring. Before, Smalltalkers used to put snippets of code in comments with the exhortation to "run this" or "debug this" to clarify how a certain part of the API worked. The problem arose that refactorings would often break those snippets. However, false ifTrue: ["Debug this" myObj := MyClass new. myObj myWonderfulMethod.]. ...was very fast (it was a jump on many VMs) and would never break even if refactorings hit it.