[eluser]jedd[/eluser]
Brian,
I use that approach all the time, though on occasion (usually when it's something a tad more complex than simply 'if something, go somewhere else') I'll stick with the long block indentation approach.
A few thoughts on the subject.
Long block indentation - these tend to appear uglier once they span more than a screen length. If you have functions that span more than a screen length, some might say that your function is too long, and should be broken down into component parts. Rule of thumb, stuff, to be sure - but something to consider if it's part of the reason you find the big-indented-block unwieldy.
I think you probably don't like it because the negated if conditional seems .. around the wrong way. Don't fret it - it's just a conditional. You're not comfortable with them, because you're not used to seeing them, in turn because you're not used to coding them. The obvious solution - code more of them.
I've read that you should have only one exit point for a given function. I guess they mean grouping of exit points, since you want to return different things based on different inputs. And I can see the argument there, though it's probably something that is easier as you get more proficient (I have exit points scattered everywhere, so I've a long way to go, mind). I think the two approaches you describe, though, have the same number of exit points, and comparable (just inverted) logic that wraps them up, with the only major distinction being that you don't need the 'else ... ' in front of your big block of stuff, because 'else' is implied by the redirect() on the line above.
From a performance point of view - theoretical, at least, because it's unlikely to ever intrude measurably on your actual system performance - you should arguably conduct your fastest tests first in any function. As I say, this is unlikely to ever impact in any significant way, but it does suggest that doing the negated test, and getting the heck out of that function sooner rather than later, scores higher points on the 'better coding approach' test.
(On that last - yes, also, equally arguably, you should do your tests in descending order of number of cases that get culled - but that implies some decent test data, and consequently implies optimisation stage, rather than initial design and coding choices. I'm sticking to that line for the time.
