In an equally named article, the excellent (yes. Really. This is one of the blogs you HAVE to subscribe to) Coding Horror blog talks about flattening out deeply stacked IF-clauses in your code.

I so agree with the guy, though there seem to be two opinions in the matter of the points 1 and 4 in the list the article provides:

Replace conditions with guard clauses. This code..

Many people disagree. Sometimes because they say that Exceptions are a bad thing (I don't get that either) and sometimes because they says that a function should only have one return point

Always opportunistically return as soon as possible from the function. Once your work is done, get the heck out of there! This isn't always possible -- you might have resources you need to clean up. But whatever you do, you have to abandon the ill-conceived idea that there should only be one exit point at the bottom of the function.

I once had to work with code a intern has written for us. It was exactly written as Coding Horror tells you not to. It was PHP code and all of it basically took place in a biiig else-clause around the whole page, with a structure like this:

if (!$authenticated){
   die('not authenticated');
else{
  // 1000 more lines of code, equally structured
}

This is a pain to read, understand and modify.

To read because the thing get's incrediby wide requiring you to scroll horizontally, to understand because you sometimes find an }else{ not having the slightest idea where it belongs to, requiring you to scroll upwards for half a file to see the condition and to modify because PHP's parser is inherently bad at reporting the exact position missing or spurious braces, which is bound to happen when you extend the beast.

But back to the quote: I talked to that intern about his code style (there were other things) and he mostly agreed, but he refused to change those deeply stacked IF's. "A function must only have one single point of return. Everything else is bad design", he told me.

Point is. I kinda agree. Multiple exit points can make it hard to understand the workings of a function. But if it's a single, well definded condition that makes the function unable to continue or if the function somehow gets its result way early (like if it's able to read the data from a cache of some kind), IMHO there's nothing wrong with just stopping to work. That's easy to read and understand and certianly does not have above problems.

And of course every function should be short enough to fit on one screen, so scrolling is never neccessary and it's always obvious where that }else{ belongs to - at least without making you scroll.

Personally, I write code exactly as it is suggested in that article. And I try to keep my functions short. Like this, it's very easy to understand the code (most of the time) and thus to extend it. Even by third parties.

Christoph, do you agree? And: No, I'm not talking about that sort-by-material-group-thing. That IS unclean. I know that (and so do you now *evilgrin*)

You know what's one of the greatest things to happen on the evening of a workday?

You come home, select 'Play Movie' on your Harmony Remote and watch the speedrun that downloaded itself while you were on the office. (using Windows Media Center. Sorry, but that has the advantage of just working).

This is the future. This is like watching TV with the full control of the program.

Why should I watch TV only to see programs I don't want to for most of the time? Why should I cope with advertisments every 10 minutes? Why should I be forced to watch all the movies in the german synchronized version?

Not with me. This is what the internet is for. This is why I'm running a linux server at home.

Playing around with Asterisk, it was inevitable for me to stumble upon AGI.

AGI is a protocol quite like CGI which allows third party applications to be plugged into asterisk, giving them full control over the call handling. That way, even non-asterisk-developers are able to write interesting telephony applications.

One thing I always wanted to do is to set the CallerID on incoming calls. Some numbers are stored in our customer database. There is no reason not to show the customer names on the phones displays instead of only the number.

The snom phones do have a little addressbook, but it's very limited in both amount of memory and featureset, so it was clear that I'll have to set the CallerID via Asterisk (SIP allows for transmission of a caller-id. And so does AGI)

Additionally, I thought, it would be very nice to use the swiss phone book at tel.search.ch or even the non-free ETV to try and guess numbers not already in our database.

That scenario is exactly what AGI is for.

As AGI works like CGI, it creates a new process for every call to AGI applications. This is not an option if you want to use interpreted languages. Well. it *is* an option considering our low amount of calls we are getting per time unit, but still. I don't like to deploy solutions with obvious drawbacks.

Besides, launching a PHP interpreter (I'd have written this in PHP) can easily take a second or so - not acceptable if you want the AGI script to be mandatory on each call. Think of it. You don't want the caller to wait for your application.

The solution to this is FastAGI, which works like FastCGI: A server keeps running and answers AGI-requests. Like this, you start the interpreter once and just serve the calls in the future. You save the startup-time of the interpreter.

Even better: It allows to run the AGI applications on a different machine than the PBX. This is good because you want the PBX to have as much CPU time slices as possible.

Unfortunately, this made PHP quite unsuitable for me: While it is possible to write a socket server in PHP (ext/posix does exist), I never managed to get it to work as I wanted to. It was slow, unstable and created zombies.

Then I found RAGI which was even better. For quite some time now, I have been looking for an excuse to do something with Ruby on Rails. With RAGI, I finally got it.

Getting the sample provided with RAGI to work was very easy (look at the README file). And reading through that sample file, I was very pleased to see the simplicity of writing a AGI-Application in Ruby (RAGI uses FastAGI, of course).

Now I can finally start hacking away in Rails to create my internal-customer-database / external-phone-lookup application (with some nice caching/timeout handling) to finally show the name behind the calling phone number on the displays of our SNOM phones.

Of course I'm going to provide the sourcecode here once I'm done.

Let's say you create some very nice AJAX-stuff for a web project of yours. With nice I mean: Not breaking the back-button where its functionality is needed, not doing something that works better without AJAX, and doing it while providing lots of useful visual feedback.

Let's further assume that the thing works like a charm in every browser out there (not counting Netscape 4.x and IE in all versions - those are no browsers).

And then, IE throws this at you:

Needless to say that the HTML output in question had a line count not even close to 370, so finding this thing easily was out of the question.

The solution: IE is unable to write to innerHTML of a TBODY element. But instead of providing an useful error message or even a link to the source with the line in question already highlighted (that's what Firefox would do), it just bails out with completely useless error information.

*sigh*

(btw: That mix of fonts in the details section of the error message is just another indication of IEs great code quality)