I have to come clean. For a long time, I've been a one-exit kind of guy. It stems from my earlier programming years and came from the desire to reduce spaghetti style coding. I used to enjoy being able to pick the point in time a routine exited, as I thought (perhaps misguidedly) that one exit made things easier to follow.

This of course leads to long drawn out routines, and nesting of operations inside a lot of if/else/end style constructs to allow you to gracefully handle the flow of code back to the one exit.

Lately, however, I have switched camps. Exit your ass off, wherever you want, as long as it's for the right reasons. Don't bail out mid routine because you're too lazy to actually figure out where you should leave, but don't ramble on and force the next poor sod to trace his or her way through your massive mounds of if/then.

This article puts it far more succinctly than I could ever do. I always check my inputs and bail out now, as opposed to checking them then if/then-ing my way to the bottom. I also return early if the function gracefully allows it. Ie, if the more common case can be realised early in the code, I'm not afraid to jump out there. It's like being forced to read the entire menu when all you wanted was a steak.

Also, I'm a big fan of the inversion of logic, as described in the article. Anyway, have a read. I'm going to subscribe to Thinking in Java. Seeing as C# is Java's long lost twin. The Arnold Schwarznegger one, not Danny de Vito...