Your very first snippet you object to is one of those things that I still say "If you're too stupid to handle evaluation on assignment, please just stop programming now"

Because I honestly don't think anyone should be so stupid as to not be able to handle the differences atwixt =, ==, and === if you just explain it to them.

Operation on assignment is a great time saver, often more efficient (particularly inside for loops).

For example:

for (
var i = 0, anchors = document.getElementsByTagName('a'), a;
a = anchors[i];
) {

Evaluation on assignment, powerful, fast — and in fact this is still the fastest way to iterate through a nodeList or other iterable where you know none of the values are loose false. Yes, even compared to Array.foreach or for/of… at least if you take all browser engines into account. (since FF and Edge are WAY slower on those Array methods than V8)

Mostly though I agree with the rest of your article. I’m often shocked how many developers make dead code, or pointless code when it comes to boolean evaluations.

Though your “Code that makes more sense” doesn’t… because it’s a static while for nothing if you know about do/while.

do {
} while (!conditionFalse());

Is far simpler and functionally identical to what you posted.

Coming from a ASM/Pascal/Modula/Ada background to me do/while — being equivalent to repeat/until — makes many times more sense than while(condition). I don’t understand why so many developers are gun-shy of it and/or have never heard of it.

Hell, this SHOULD be more efficient than a for loop:

var loops = 10;
do {
// something
} while (--loops);

And is in most languages since it directly translates to how assembly works, but for some reason in languages like JavaScript and PHP it’s less efficient. Really stupid since you’d just load the count into ECX, REP or LOOP whatever the operation is, and be done with it. Actually one of those corner cases that explains why compilers often fail to be as optimal as they could be. Also one of the few places I think Ruby got it right.

I also think that we need a return to the use of control characters. They’re more efficient on bandwidth than JSON or XML, are capable of similar structures, and are very easy to do splits on compared to other data since you can strip them from the data entirely in most cases. I often use them in AJAX for just that reason. For me, there are a LOT of times looking for control characters make sense.

Hell, even just changing double /r/n to <p> wrappers and singles to <br> is a valid reason to use hunt for control characters. Just like how you’d look for /x00 when data is null terminated.

I’m really not sure why you think that’s bad or what justification you have for what’s basic functionality being a “mistake”.

With debugger statements the way I like to handle it is to add a comment /*debug*/ at the start of the line, as I have my own little processing script that strips out any lines that start with that for deployment. That way you can put them in, but be certain they do not get sent to client-run code. The same goes for console logging.

Though using a proper debugger and setting breakpoints is a far better approach, a lot of times it just doesn’t work as expected.

Overall though, you do point out some common follies and foibles.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store