Example One is MUCH easier to read. I've always hated the reverse logic coding. If you want True then check for True, don't check for something other than False. It's asinine logic. The more specific you are you the more accurate your results will be. Yes there are times NOT is better, but when evaluating a basic True or False expression, be specific.
I would have to say the first is faster. In every reference i read about it, it has to switch True and False THEN evaluate the expression. While I could be wrong, logic does seem to point in that direction.
--------------------------------------------------
Bluto: What? Over? Did you say "over"? Nothing is over until we decide it is! Was it over when the Germans bombed Pearl Harbor? No!
Otter: Germans?
Boon: Forget it, he's rolling.
--------------------------------------------------
I agree with ousoonerjoe in pretty much every aspect. As long as you are not doing something like this:
Code:
If something = false Then
Else
End If
You should be okay. Evaluating like the above is bad because you have to do a boolean check AND a comparison check. The comparison check is not necessary in this case.
While evaluating for True is easier to read, I am not sure that using the Not True check will be any worse as far as performance goes as long as you are not evaluating millions of records at a time.
In my opinion, the processing time necessary to negate a False to True should not impact your performance at all unless you are hammering through a lot of records....
=======================================
People think it must be fun to be a super genius, but they don't realize how hard it is to put up with all the idiots in the world. (Calvin from Calvin And Hobbs)
Robert L. Johnson III
CCNA, CCDA, MCSA, CNA, Net+, A+, CHDP
VB.NET Programmer
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.