JavaScript: The Bad Parts

Web Geek Warning

Last night I headed over to the Paypal/EBay offices to see a presentation by Douglas Crockford, titled Programming Styles and Your Brain

I'll admit that I was a little bit skeptical about coming away with much useful information (a general rule: be cautious around tech companies that have had near-zero evolution since, oh, 1995), but in fact the debugging bits were pretty illuminating. Here are some sketchy notes:

Your Brain

Crockford’s lecture had about five introductory minutes of broad speculation (he's earned the right!) mixed with notes cribbed from Daniel Kahneman…

• Computer programs are the most complicated things humans make
• Humans suck at making such things
• They make mistakes
• They confuse “hardly ever happens” with “never happens”
• They confuse reading two threads on a jquery forum with an education
• They write in C++ when the language is not C++ (or Java, HLSL, python, Mel, Fortran…)
• They mistake complex obscurantist “cool” with professional “clear” coding
• The human is almost always the limiting factor in software
• Being consistent in style is the easiest way to avoid common errors (especially forms that are difficult to distinguish rom errors, which in JS are many)
• Anyone can program, few can debug

JavaScript

This was the expected real bulk of the presentation, a longer not-veiled pitch for JSLint and his book “Javascript: the Good Parts” -- especially about how to avoid the bad parts:

• Auto-semicolon closure. This burns people so, so, much, and is one reason where it really does make a difference (for polyglot programmers) to get in the habit of putting the curly open-brace to the right of the if() clause on the same line, rather than on the line below – just like K&R intended.
• Stupid multi-line strings that use “\” at line breaks because the parsers don’t recognize trailing spaces and the editors don’t show them.
• Mistaking the scope of “var” to be block scope (like C, python, etc) – it’s function scope, so avoid declaration-inside-the-block constructions like for (var i=0;…) { … } because it won’t get declared where you think it is. I know I make this error a fair bit.
• Make global variables REALLY_OBVIOUS. Since there are no macros in JS, THIS_IN_ONE_WAY (clearer than, say, Hungarian). In general avoid globals, except that you can’t because that’s how modules link (no linker).
• If using immediate-invocation functions, put the final () inside the encapsulating () parens – e.g. (function() {…}()); not (function() { })(); – the latter wrong construction he called “dangling dog balls style.”
• Avoid “==” because it does type conversion and different interpreters convert differently! Is (‘’==0) true or false? Use “===” instead, for a direct comparison.
• Avoid the “switch” statement or at least be obsessively diligent about having break statement in every clause -- and having a default case.
• Avoid the “with” construct. Consider: with (o) { foo=koda; }
  does it mean:
  • foo=koda;
  • o.foo = koda;
  • foo = o.koda;
  • o.foo = o.koda;
  ??? Different interpreters DO give different results!
• var a = b = 0; in JS is the same as /*global */ b = 0; /*local */ var a = b; -- NOT like C.
• Not only are “var” declarations hoisted to the top of the function scope, so are function declarations. So beware dependencies that are not resolved! NO ERROR WILL PRINT. Better to just put the var and function declarations at the top of the enclosing function
• Avoid the “new” pseudo-class construct, not because it doesn’t work but because people often forget to write “new” and then they may accidentally trash that global class-like definition and you are hosed. Just use simple {objects}
• If you have constructor functions indicate them “LikeThis()” to distinguish them from “all_other_functions()”
• Avoid “++” which is a leftover from pointer arithmetic days. Just use “+=1” it’s just one more character to type, using “++” doesn’t make you more efficient, it makes you sloppy (especially when few people remember that i+=1; is not i++ -- it’s ++i;)

The Bad Parts?

So how does the Javascript on Botzilla stack up? Let's just say, it's an ongoing learning process!

In scanning the scripts here (and at Trion), there appear to really only be a couple of idoms that I need to stamp out from my code to make the analyzer happy. What's yet to be determined is if Javascript's scoping rules will ever really make sense...