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...

Posted June 22, 2012 | Comments (0)

My Portable Office

bjorke_travoy.jpg

Bike Friday Pocket Rocket + Burley Travoy + Samsonite

Posted June 12, 2012 | Comments (0)

Pescadero Phone Panoramas

bjorke_pescadero.jpg

bjorke_pesca2.jpg

bjorke_pesca3.jpg

bjorke_pesca4.jpg

Posted June 10, 2012 | Comments (0)

Black

Fluid is the new Black goes the saying of the day, but for Botzilla the main message is: get over it.

By that, I mean that if the site needs to work on all possible screen sizes, for future-friendly leanings, then: the pictures are just going to have to be small. And there's the rub for a photo site -- when the pictures are reduced to being upgraded versions of the thumbnails, not the other way 'round. This is tough, and frankly I won't give up without a fight for getting the best possible photographic presentation into place.

At the moment, I'm getting cozy with this little bit of CSS:

img { max-width: 100%; }

Which is a trick to ensure that images are resized downwards as their containers shrink.

The obstacle on a site like Botzilla is that most photo <IMG> tags have both WIDTH and HEIGHT properties specified, so that when displayed on a small screen, "max-width" alone doesn't get you very far -- the images don't scale uniformly down, but instead simply compress horizontally, untill they're long tall sticks.

JQuery to the Rescue!

Including this as the first line in my ready() function does the trick:

$("img").removeAttr("height");
Posted June 06, 2012 | Comments (0)

 

All content on botzilla.com is ©1994-2017 by Kevin Bjorke. All Rights Reserved.