December 11, 2003
Pulling a zoolander
Posted by Jess in
Tech Talk
Ben Stiller, as Zoolander in one of my favorite movie quotes: "They'll be looking for us at Maury's. But they WON'T be looking for... (pause)... not us."
Sigh. I always thought that was such a funny line, how Zoolander couldn't figure out how to make something out of nothing.
But then I realized that it's the same problem that plagues me every time I have to write an IF statement, write it backwards, and then can't for the life of me figure out how to reverse it. Every time, I always want my test to do nothing the majority of the time.
If
THEN DO NOTHING!
Else
DO THIS OTHER THING
A good example of what gets me every time is when I want the value to do something, except when the value is blank. I stumble over myself. I can't even think of ways to reverse the statement so it makes more sense to me.
If num=""
Do nothing
Else
do stuff because num is something!!
I usually end up 'zoolandering' it as such:
If NOT num=""
do stuff!
However, I have no idea if that's a terrible approach, or a good approach, or the ONLY approach. Or, do I wrap the entire code around a different statement?
I have no idea what sort of childhood trauma induced this "If anxiety". Probably when I was eight and had a 400-line BASIC program written, then realized I needed to insert a line right in the middle and re-number them all.
I think it's because for some reason, even though I always end up at the same point as everyone else, I feel compelled to take the long way around to get there. If I'm standing facing foward, and need to end up facing the left, 9 times out of 10 I will make three rights instead of one left. Don't ask me why.
But at least I get there. Though I usually have to ask Matt for help. At least with the IF statements. ;-)
Permalink
|
TrackBack (0)
Comments
wow, i never saw that movie. and if i had, i don't think i would have made that particular connection to programming. you have a very interesting brain! now whenever i do that if not then do that thing, i'm going to think of zoolander... which of course i am now going to have to see!
thanks :-)
I have a very interesting brain... "he said tactly".... :-) LOL.
I hearby start a new buzzword: Is jonvon the next one to zoolander his code? :-)
LOL...
Jess, Gosh, I figure that since people time is much more expensive than CPU cycles, it makes sense to keep the code readable. So I'll often write IF statements like:
If myField = "" then
' Life is good so keep on truckin
else
' Looks like we've got work to do
do some awesome stuff
endIf
I do typically add a comment in the 'do nothing' place in an attempt to make it readable. If it gets too frustrating, then I just take a break and pop online to see if anyone sells a Zoolander-sized cell phone yet :-)
Cheers!
Thanks Joe!!!
See, I always wanted to do it that way, which seemed logical to me, but I never, ever thought of just sticking a comment in there so SOMETHING was there.
Me likes.
LOL, I could never have a phone like that.. I'd think it was a hershey kiss or something and eat it by mistake. :-D
I don't think there's anything wrong with that approach. The most important thing is that what you write is straightforward and easily readable. For instance,
if not something:
then do another thing
That makes sense; it's saying do one thing if it's not something (say, null, or something). But what you want to avoid is a "double-negative", because that usually is pretty weird to read for your cow-orker who comes along after you.
if not something:
then don't do another thing
In this case you can just invert your logic and say:
if something:
then do another thing
Also, some languages support the use of objects called Exceptions, which let you "go out on a limb" and just do stuff without worrying about the conditions:
do something
do another thing
do one more thing
whoops:
clean up the mess
The "whoops" section is only "triggered" if something unexpected happened during the first three steps. (Obviously this isn't a real programming language, though it would be funny if there were one that used "whoops" to catch exceptions!) The nice thing about exceptions is that they can make the code more readable, since you don't have as many IF statements/conditionals, but they don't obviate the need for conditional statements altogether -- there's always going to be times when your program needs to make a decision between two paths based on some condition.
Having a "whoops" section where you can "clean up" a mess is essential for object-oriented code using a technique called polymorphism. (Kind of like the magic spell ;) Matt would be better able to explain it than me, but the idea in polymorphism is that you don't go through a cycle of tests to test the type of the object:
if my object is Red: then do one thing
if my object is Blue: then do a different thing
if my object is Green: then do a totally different thing
Rather, you would just pass the message "do something" to the object and trust the behavior programmed into the object to "do the right thing", and if there is for some reason a problem, you catch the exception and deal with it.
tell colorObject to do something
whoops:
generate an error dialog
Speaking of whoops, I just realized I geeked you out at 6:45 in the morning. Gotta go shovel the driveway now. ;)
Still, there's nothing wrong with either:
throw(Exception whoops);
(or, in VB.NET, Throw(Whoops As New Exception))
or
catch(Exception whoops);
No matter how you look at it, there are going to be people who consider the approach wrong for one reason or another.
If Not Thing = RightThing Then
'reams of code
End If
is going to draw hits from the "stop with the negative waves, Moriarty" crowd. On the other hand,
If Thing = RightThing Then
'do nothing radical
Else
'reams of radical code
End If
you're going to take a beating from the "never leave an empty code path" crowd.
Exceptions aren't necessarily a good way to handle the situation either (and I am a huge fan of exception methods). Exceptions should handle exceptional situations, not be used as a substitute for an "if" in an expected condition. If your fully-validated numerical field holds a date, that's an exception -- if it holds a number less than zero, and your calculations allow for that, then it's an expected condition.
Then again, the only stylistically-correct programs ever written are do-nothing examples in CS textbooks. Oh, and:
tell turtle walk 10
LOL, or just use case statements and call it a day.
I guess it is like Matt always said when he used to umpire: no matter what the call, there will always be 10 happy people, and 10 unhappy people.
Erik, your email link doesn't work on your site...FYI.
Hey Stan,
In nearly every language it's conventional for exceptions to only be used for exceptional conditions, but it's actually idiomatic to use an exception in Python as a safeguard against a runtime error (such as passing the wrong message to an object [aka invoking the wrong method]). See '"It's easier to ask forgivness than permission" vs "Look before you leap"' ( http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52291 ).
Hey Jess,
No I got your email but for complicated reasons (I'll explain) I haven't had a chance to reply! But I will when I get home later in the week.
