There is nothing to see here, go away please. :) It's just the simplest way of turning a code fragment on/off. Not pretty, but not the end of the world either. :)
In C, at least, compared to the commented out version or removed (when using versionning) variant, the code is still present and builds (and will break upon API change, guaranteeing it to be up-to-date), is present when re-factoring (not necessarily easy with all version control systems), and has no impact over performances (might not be true with PHP). So this can be seen as a feature, actually.
Sure (if the code shouldn't just be deleted at all and kept in version control), but I'd rather shove the magic constant and it's explanation into a variable at the top of the file:
// PHP has a bug that prevents you from creating a byte array via variants
PHP_BUG_123_RESOLVED = false;
So, getRandomInteger() keeps fetching bytes and adding them as 0..255 values until it reaches the desired value? How silly is that?
For a random number between 0 and 2147483648 it would require 8388608 random bytes.. omg!
I think you just found out that PHP is a very widely used programming language. To make a more meaningful comparison, divide by the total lines of code.
[-][[This reminds me of Brainfuck,
where a similar hack can be
used to write comments with
arbitrary contents -- even
containing "]" if you ba-
lance them right.]
I only delete code I know I'm not going to use later.
Refactoring, especially renaming files, WILL make it next to impossible to find "that one bit of code you know that does the trick", because even with a rgrep or git blame it will not turn up.
As soon as the commit history is >50 commits, it's also not feasible any more to scroll through hundreds of pages of diffs.
Side note: find a way to easily store "intentionally dead" code in a file, in a way that it does not show up in the code, but can be searched at least on the commandline - easy way to get rich. Devs all over the world will love you.
(I'd imagine replacing a block of code e.g. with /* REMEMBERME /, git detecting this block (and inserting a / REMEMBER-ID 12345 */ instead), and git supporting a command like "git show-dead file.c" which shows all the dead code, too.)
Indeed I was, yet still this forces me to remember a part of the string of the code I deleted... which may not be the case if the commit was a month or two (or more!) ago. I mostly remember just "ah, this was in class XYZ"... open it, quickly scan the file for the comment blocks and voila, there's my code.
I only delete code I know I'm not going to use later.
Refactoring, especially renaming files, WILL make it next to impossible to find ...
It won't, if you use proper commit messages. Once you start doing that, you'll soon discover it will make everything much more discoverable. Apart from that, death to dead code! Having worked on a project where about 10 to 20% of the code was effectively dead (either simply unused, commented out, #ifdef'ed away of if( 0 )'d away) I can assure you I never ever want that again, mainly since the dead parts still turn up in every search/grep/find reference.
That's great, if you work by yourself and are very disciplined. In fact most of us work in very undisciplined teams - I could myself lucky when colleagues write a descriptive comment at all.
For things like this, I just remove the code and leave an explanatory comment indicating what's not there anymore and why, and what revision it was last seen in.
I also hate it when people comment out code without commenting on why is it removed, why doesn't it work, what to do to make it work, who has done it, who is going to make it work and so on...
Have you read the comment? This disabled part of code is used for communication: "If someone is able to circumvent this problem, please email me". When someone reads the code to discover why it works in a certain way, they'll instantly learn that the developer thought about this, and tried to do something, but discovered that an external bug prevents him from enabling this code.
It's also common to include TODO, FIXME, or BUG comments into code. Sure, you can put them into issue tracker, but having them directly in code gives more context.
And then the next person looks at the code and thinks why don't they just do x. Then x doesn't work so they delete it again. Then the next person looks at the code...
In Common Lisp there's a special syntax to make the reader ignore an expression, for example #+feature(code here) is executed only if feature is present. It's common to see code commented out with "#+(and)(code here)" or "#-(or)(code here)". In fact there are proponents for either one of these idioms. I guess in Algol-style languages it's rarer to see code commented out like that?
I haven't done enough C to need it, but it's a relatively common C idiom (not sure about PHP though). It's usually used with a goto jump (label inside if (0)) to clean up after an error. That way during normal execution the label code never executes. (I hope I remember this correctly.)
