See the problem? Really, there are a few ways this can go wrong. To a quick glance, the only clue that line 14 (“interpolate a comma”) is part of a conditional is its indentation. The indentation is important to a human reader — but absolutely irrelevant to the PHP interpreter, which simply treats the next line after the conditional as the conditional’s block. Regardless of how it’s indented, and regardless of what else is around.

The way it looks to a human is not the way it looks to the machine.

What happens if someone wants to add some logging? What if they add it after the comma line?

Now the log claims the code has added a comma, even when it hasn’t. But still, it could be worse! What if you decided to add your logging before the other line?

Now it adds a comma no matter what — even the first time through the loop, when the string is empty. So instead of a string like '123,124,125', $itemId will now have a leading comma: ',123,124,125'. Since this value is getting stitched into a SQL query later on, it means your app will blow up with a SQL syntax error.

This is why Python makes whitespace significant to program flow. The way the indentation makes it look like the logical structure is, is how the structure actually is.

And this is also why Perl — of all languages, one that normally errs on the side of letting you leave out anything that can be inferred from context — Perl insists in its syntax documentation that in cases like this, “the curly brackets are required — no dangling statements allowed.” (It then says, in typically Perlish fashion: “If you want to write conditionals without curly brackets there are several other ways to do it.”)

If you’re working in one of those languages that lets you omit curly braces around a single-statement conditional — DON’T DO IT! The potential maintenance and debugging problems are not worth the fun of saving two keystrokes (or just one, if you work in an editor that auto-closes your braces for you).

Because of the way JavaScript’s search() method works, you can do:

Try running this, and it will correctly claim that “Your URL is http://kai.mactane.org” — even though there’s a ! at the beginning of the test. What gives?

That exclamation point looks like it’s saying: “If the search for http://kai.mactane.org within the given string fails…” But what that test is really saying is: “If the search for http://kai.mactane.org returns Boolean false — or anything that evaluates as Boolean false…”

What that search() call actually returns is the character index at which the needle is found, or -1 if it isn’t found. Since the needle is found at the very beginning of the haystack — at character index 0 — search() returns zero. Which evaluates to false in a Boolean context.

If the needle isn’t found, the search will return -1 — which evaluates as true in a Boolean context!

Effectively, the ! operator is reconciling the disagreement between search()’s idea of falsehood and if()’s idea of falsehood: search() returns -1 for a false result (a failed match), but if() considers -1 to be true, not false.

This trick only works with needles that you are sure will only occur at the beginning of the haystack.

Once again, you should never, ever actually write code like this for any serious purpose or in anything you intend to deploy in the real world. The maintainability problems are not worth the amusement of confusing all your co-workers with a test that looks reversed. Instead, use a positional anchor in your regex, and explicitly test against -1…

…like any sensible JavaScript coder. (Yes, that last bit is intended to be ironic. I wrote something once about the silliness of having to add that extra test; I’ll have to see if I can find it and republish it here. )