Uncommon Sense (for Software)

Podcast #1: Coloring Outside the Lines with WordPress, Thesis, Firebug, HTML & CSS.

Just tried my first podcast.

While (EndlessLoop): Sit there and wait;

I think the "While" loop in programming languages needs a refresh. More and more software these days is being pushed to Web servers, which is essentially a "shared hardware" environment. Which means, one little runaway endless loop can pin the CPU and ruin it for everyone (sometimes, thousands of other users). Sure, if set up properly, the Web server should be killing the process after who knows how long (a minute?), but then it's a hard quit and the application doesn't get a chance to do any sort of recovery. With desktop software, this is much less of an issue because the one and only user will notice a hung process and has a few options (wait & hope, kill it, exit other apps first, then kill it, etc.)

While loops are the biggest culprit. Sometimes whatever is inside the loop is complex enough that it's possible to miss a case that should trigger the loop ending. From a defensive coding point of view, every (EVERY) While loop I code has a check for some reasonable maximum number of loops. If that limit is hit, it throws an endless loop exception. It's usually easy to pick some number that is so high that under normal circumstances will never be hit, but in the case of a bug, you can hit 10,000 or so loops in about 200 milliseconds and break out of the loop before any users even notice.

I can't tell you the number of times that practice has worked. It means you get an exception thrown (which you can catch and report), rather than a pinned CPU and unresponsive Web server. It works so well in fact, and costs so little (think of a really big number that your loop should not normally hit under regular circumstances), that I would love to see a new mandatory parameter built into While loops: maximum loops. Something like:


While (ThisDate < ThatDate; max: 100000)
{
}


Even if the "max" parameter allowed for some constant such as "unlimited", at least with the compiler enforcing the presence of that parameter, it forces us as developers to remember that what we're doing has an endless loop as a potential side effect - which in the case of a server-based application, are some of the nastiest possible bugs because they hurt all the other users at the time as well.

Joel on how the JavaScript performance thing is a temporary problem. Now get back to writing maintainable code.

I have a pet peeve about how some of the more popular JavaScript libraries today have awfully awkward syntax (for these modern times in which we live). All these inline objects, terse names, passing function literals as arguments to other functions, and so forth. Icky readability. Sure, JavaScript is a very "expressive" language as they say. And yet ironically enough, readability of modern "fancy" JavaScript is on a downward trend.

The causes? The unfortunately reality that JavaScript is an interpreted language, and therefore slow. So we have to jump through all sorts of arcane hoops to make up for it. Here we are in 2007 and people are worried about kilobytes and counting characters again, long after wonderful inventions like language auto-complete and intermediate languages (IL's) to achieve some compromise between interpreted and compiled languages.

Joel writes about how performance is a relatively short-lived problem since machine power and bandwidth are increasing so rapidly. My favorite part is:

Heck it’d be a complete rewrite; the whole programming model is upside down and recursive and the portable programming language has more parentheses than even Google can buy. The last line of almost every function consists of a string of 3,296 right parentheses. You have to buy a special editor to count them.

Cracks me up.

Closures and inline functions are to JavaScript what pointers were to C++. With all that extra power comes a lot of extra responsibility (read: risk) - too much for most people to have to deal with in all but about 5% of application development. Remember that a lot of system (low level) software is still written in C++ for its extreme speed and power, but most of us still use higher level (simpler syntax) languages.

Counting Keystrokes in Code

I can't tell you how much this irks me:

$A(someNodeList).each(function(node) { alert(node.nodeName + ': ' + node.innerHTML); } );


This is a horrible style of code being popularized by the very trendy Javascript library, Prototype.

Let me say that I am absolutely thrilled to see an army of smart people really going to town with Javascript lately. I mean it really seems that there isn't a single nook or cranny that hasn't been fully explored and documented by someone out there somewhere. Javascript is coming into its own as a real development language thanks in part to some folks showing the world that it's not just for "scripts" and "glue code", but in fact is probably the new user interface language for the Web, and it's here to stay. We're seeing whole toolkits and class libraries coming out in Javascript. Great stuff.

But this syntax is terrible. It pretty well guarantees that the code is unreadable by someone that has not taken the time to sit down and learn Prototype first. It makes the library noticeably less accessible to the intermittent developer who needs to quickly get in, understand a piece of code, fix a bug or make a quick change, and get the heck out.

Here are just some of the problems:

1. Guess how long it will take you to forget what $A('') does? Not very long. Did you know there is also $R(''), $F('') and about 3 other one letter function names too? What do you suppose they do?
2. Some languages have had iterator functionality built into their grammar, with phrases like "for/each/do". Prototype tries to add this as a method call on a collection. Why? To save the 2 extra lines of code it takes you to write out an explicit FOR loop and to make using nested statements and function literals easier to use. And the benefit of that is? Minimal at best. We're talking handfuls of keystrokes per block of code.
3. One of the things that fueled the adoption of Web technologies like HTML, CSS and Javascript in the first place is that they were EASY and ACCESSIBLE - therefore everyone adopted them. We collectively chose a verbose text format for all of these protocols and languages versus MUCH more efficient binary alternatives. We did this because they were human readable and the benefit of that out-weighted the cost of the extra size. The barrier to entry for developing apps dropped significantly and we have all benefitted from that. There's far more exposure to function literals, closures and class prototypes than there needs to be for the overwhelming majority of developers today.
4. With a loosely typed, interpreted language, the only clue you have as to what you're supposed to pass into method calls is the verbosity and/or naming conventions of the methods! And we're using single letter function names?! This feels like a giant step backwards, and very exclusionist. Like "if you don't know our syntax, you're too dumb to play with us."

This reminds me of the old C++ days when developers proudly demonstrated how much code they could cram on one line. People scratching their heads trying to figure out what the difference between b = b++ * 5 and b = ++b * 5 was.

Then one day the development community realised that code readability and maintainability was far more important to the business than saving a number of keystrokes. People starting writing more explicit code again.

Then came Intellisense which pretty much banished the practice of writing terse code. You could actually only type req.wr("hi"); and the dev studio would actually write out for you Response.Write("hi");. You saved the keystrokes, and everyone else knew what the hell you wrote. Even if you didn't even know the language too well, you could stumble along and understand what was going on.

Even better, you actually LEARNED as you coded, because drop-downs were popping up and getting auto-dismissed as you typed, so that you were seeing property and method names flash in front of you as you typed. It was a sort of learn as you go method.

I learned C# about 2 years ago and have never picked up a book, simply because the dev studio has Intellisense.

As far as I can tell, the only pseudo-legitimate reason for developing a library with as terse a syntax as Prototype is that in large code files, you do save some bytes which can be a little bit of an issue since we're throwing Javascript libraries across the wire with each page load. (By the way, most browsers and web servers support GZIP'ing the Javascript files on the fly so that you're really not saving many bytes at all by using short identifiers).

But it's only a matter of time before someone comes up with a great Javascript dev studio that gives us Intellisense so we can save those keystrokes and yet still produce readable code. Someone else is going to come up with a reliable (and automated) way of packing our Javascript so that redundancy is compressed out and we no longer have to choose between the readability of AsArray(someNodeList) and the small size of $A(someNodeList).

When that day comes, will all of these new fangled Javascript libraries be re-written so they are actually readable and maintainable by someone that does not live in them every single day?

I think that while there's some really good work going on in the Prototype (and other library) teams, the terseness of the syntax could spell its own doom as soon as someone comes along with a library that does just as much, but with an easier syntax, Intellisense for "keyboard efficiency" and packing for "over the wire" efficiency.

Somehow feels like we've learned this lesson before... Seems very familiar indeed...

Fixing Cross-Browser CSS

Please. I beg you. If you are developing any kind of web-based software, read this.

We all know that in magical gum-drop land "standards" like those put out by the W3C would save developers from even having to think about cross-browser development issues. And I'm happy to see that with the modern browsers these days, the standards have gotten us about 80% of the way.

But is 80% consistency across browsers good enough? Hell no! Sure, you can easily make something work in each of the major browsers, but I think we should strive to having our software look and behave identically the same across browsers, wherever possible.

This used to be a much harder debate for me to carry on until I discovered this little trick that I'm about to describe. You'd have to put yourself through agonizing trial and error to uncover how you could structure your CSS so that it looked the same across browsers. I'm talking things like vertical text alignment of labels beside controls, some border treatments, table cells, and so on.

But now, with this little trick, it's so easy it's embarrassing. Which means that there's no good excuse for not using it! I honestly can't remember where I read it. I didn't blog about it sooner because frankly, I thought it would make the rounds instantly and I wouldn't need to (I tend not to report on the same ol' stuff going around on its own). But no. So here it is:

1. Check the User Agent string on the server during a page request. You'll get something like "IE5.5 Win blah blah blah". Search for UserAgent strings and you'll find an exhaustive list.
2. Based on the UserAgent string, add some CSS class names to the Body element in your HTML, like "Windows IE" or "Mac Firefox" based on whatever you can discern from the UserAgent string. You can even go so far as to stick versions in there like "v1" or "v5_5".
3. Now that you've marked up the Body element, in your CSS files, when you have a selector like "div.ThisSection {color: red}", you can simply prefix it with whatever UserAgent based CSS class you added at the server, like ".IE div.ThisSection {color: orange}" to write browser, O/S or even version specific rules. You can even combine them like ".Mac.Firefox.v2 div.Section {color: blue}" to grab specific combinations of O/S, vendor and version specific rules
4. Now, code your site or app for your browser of choice, and at the end of each file, you can have the 3 or 4 browser specific exceptions that tidy up the look & feel where there are browser inconsistencies.

I find that by doing this AS I CODE (not when I'm all done a site or app), it adds almost no extra development time. If I wait 'til the end of a project, then it's a royal pain in the butt.

It's important to do this on the server before the page is served to the client. If you add the CSS classes to the Body element in Javascript during the OnLoad event, the browser will likely render the page first, then re-render it after the OnLoad event, which gives you a little flicker.

It's a wonderful trick, hack free and wish I could remember where I stumbled across it so I could give credit.