• (cs)

    That's not l33t at all :(

    It should've been: MsgBox("File not found!")

  • (cs)

    if comment_frist = true then doThings() else if comment_frist = false then doOtherThings() else MsgBox("omfg haxor alert") End --terminate program end if

  • Paul (unregistered)

    Someone in 2007 already commented that they found this in their VB program.

  • pcooper (unregistered)

    You can run into issues in VB (pre-.NET) if you call into other components (COM or OCX or the like) that don't treat a VB Boolean as an integer that should be -1 or 0. If the component, for instance, stuffs a "1" in there (like a variable Value), then 

    Value = True
    will be true, but 
    Not Value = True
    will also be true, because 
    Not Value
    is the bitwise-not of 1, which is -2, which still isn't 0.

    This has lead to code along the lines of:

    Value = (Value = True)

    Along with of course a long comment about why it was needed.

  • Bongo (unregistered) in reply to Paul
    Paul:
    Someone in 2007 already commented that they found this in their VB program.
    You're either a savant or your mind is a infinite junkyard. Remembering a five-year-old (!) comment (!!) found on second page of comments (!!!) ... Now that's something!
  • daef (unregistered) in reply to Bongo
    Bongo:
    Paul:
    Someone in 2007 already commented that they found this in their VB program.
    You're either a savant or your mind is a infinite junkyard. Remembering a five-year-old (!) comment (!!) found on second page of comments (!!!) ... Now that's something!

    winrar!

  • (cs) in reply to Bongo

    Even scarier, he used the search field in the top right to search for "omfg haxor alert!" >:)

  • (cs) 
    MsgBox("lol how does I code")
    I like this version better.
  • Honnza (unregistered) in reply to pcooper
    This has lead to code along the lines of: Value = (Value = True)

    Along with of course a long comment about why it was needed.

    Why? a simple 

     //normalise return values from external libraries
    should perfectly suffice.

    Captcha: ratis - my ratis [sic]

  • Zoefff (unregistered)

    If only Rena would have been writing PHP, then a similar construction might even come in handy...

  • Frank (unregistered)

    The real WTF here is Visual Basic used together with the term professional programming ...

  • (cs)

    And now with nullable booleans...

  • MrBester (unregistered)

    I'll just leave this here...

    For the lazy, it's a definition of MsoTriStateEnumeration, which is a tri-state Boolean with 5 possible values of which only two are supported. Just let that sink in for a while so you can appreciate the awesome WFTery of it.

  • (cs) in reply to Honnza
    Honnza:
    This has lead to code along the lines of: 
    Value = (Value = True)

    Along with of course a long comment about why it was needed.

    Why? a simple 

     //normalise return values from external libraries
    should perfectly suffice.
    The problem is, such code sounds more like "validate" than "normalize".

    An actual normalizing code would do this instead:

    Value = (Value <> False)
  • Abico (unregistered) in reply to Frank
    Frank:
    The real WTF here is Visual Basic used together with the term professional programming ...
    Hey, there was a time when it made sense. It was the easiest way to whip up any sort of GUI in Windows, and it was the best way to automate Office. Before ASP or even Java, I used VB to write dynamically-generated HTML.

    But today, yeah, WTF. Nonetheless, I know a worldwide company using a VB6 (yes, VB6) application for realtime (i.e. 1kHz+) data collection, because that's what their non-programmer engineers wrote 15 years ago and they won't let go of it.

  • (cs) in reply to Bongo
    Bongo:
    Paul:
    Someone in 2007 already commented that they found this in their VB program.
    You're either a savant or your mind is a infinite junkyard. Remembering a five-year-old (!) comment (!!) found on second page of comments (!!!) ... Now that's something!
    Or both. Or he was one of the people involved.
    Zoefff:
    If only Rena would have been writing PHP, then a similar construction might even come in handy...
    That result is... very interesting.
  • (cs)

    Since True in VB (and VB.NET IIRC) is -1, when I want to convert a boolean to an integer I usually end up multiplying it by True so I get 0 or 1 as an output, like other, more sane languages. Fun.

    Although VB.NET could have True as 1 for all I know, but I multiply it by True just in case...

  • (cs) in reply to MrBester
    MrBester:
    I'll just leave this here...

    For the lazy, it's a definition of MsoTriStateEnumeration, which is a tri-state Boolean with 5 possible values of which only two are supported. Just let that sink in for a while so you can appreciate the awesome WFTery of it.

    From that page:

    msdn:
    Office enumerations with jScript To use the MsoTriState enumerations in a WSF job, add a reference to the installed Microsoft Office Object Library. Using the object name will not work if the type library is not properly set in the registry, etc...

    Instead of What-The-F, it's a What-Sa-F job?

  • Duckman (unregistered)

    This is simply standard practice in the industry. Consider one of the most central functions in the Windows API, namely GetMessage. The description is available here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms644936(v=vs.85).aspx

    Notice that it returns the type BOOL, suggesting a boolean value.

    Now read the description of the return value.

  • golddog (unregistered) in reply to Frank

    A couple jobs ago, I worked for a place which preferred VB to C#.

    Going in, I thought, "OK, it's the solutions to problems which make the job interesting, not the language in which they are written. So, it will be OK to work in VB."

    I could not have been more wrong.

    In addition to working with (by far) the least talented group of people with which I've been unfortunate enough to have an association, the main application was VB6 (although the newer things were .NET, somewhat less bad).

  • Whatever (unregistered) in reply to Frank
    Frank:
    The real WTF here is Visual Basic used together with the term professional programming ...

    OMG you are sooo cool, can I kiss the ground you walk on?!?!

    Bitchin' about vb was cool 10 years ago, vb.net is a decent language, and if you cannot make decent software with it, the problem lies with you...

    Now run along and play...

  • (cs) in reply to Frank
    Frank:
    The real WTF here is Visual Basic used together with the term professional programming ...

    Well, "professional" in the same sense that a $15 streetwalker is referred to as a "professional". i.e.: "does nasty things for money".

  • Andrew (unregistered)

    Rena forgot FILE_NOT_FOUND.

  • PassingMadrid (unregistered) in reply to The MAZZTer

    So does this mean two rights make a wrong?

  • (cs) in reply to PassingMadrid
    PassingMadrid:
    So does this mean two rights make a wrong?
    No, but two wrights do make an airplane.

    -or-

    No, but three rights make a left.

  • Nemo (unregistered) in reply to PassingMadrid
    PassingMadrid:
    So does this mean two rights make a wrong?

    No, but three rights usually come out to a left.

  • entheory (unregistered) in reply to Paul

    How in the hell would you even remember this? haha

  • NaN (Not a Name) (unregistered) in reply to Duckman
    Duckman:
    This is simply standard practice in the industry. Consider one of the most central functions in the Windows API, namely GetMessage. The description is available here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms644936(v=vs.85).aspx

    Notice that it returns the type BOOL, suggesting a boolean value.

    Now read the description of the return value.

    Wow, I wrote C++ Windows apps for years. while(GetMessage()) is a common core for many of them.

    Of course, this is a legacy of C not having a true boolean type and not being typesafe

  • Geoff (unregistered) in reply to Whatever

    I would even go bit farther. The problem with VB6 and prior was never the language. Yes it some pretty epic syntax fails, but what language does not?

    Truly the real problem with classic VB is error handling. If it was not for the On Error Goto paradigm, which totally destroys the structure of what otherwise might have been well organized quasi OO programs with VB's limited classes.

    The real trouble with VB though was it was a little to easy to get into something beyond your depth. Getting beyond a "hello world" in C++ pretty much requires at least an hour of reading for someone who has never written a line of code before. Where you are bound to pickup a little something on typing and scope. VB would let people build half their (trivial) forms application drag and drop and glue it all together with global variables of type variant.

    It would mostly work to, and then said app would grow to something less trivial with lots of cargo cult cult code and it would still mostly work. By this point the author would think they knew this programming stuff and start tackling larger and larger projects until they hit a proverbial brick wall somewhere at 200mph.

  • (cs)

    Makes me think of a nice feature in excel: This formula looks safe doesn't it: =IF(B1=0;0;100/B1) First check if what you're dividing by is not 0 (as you should).

    Now if you put the boolean false into B1... then false=0 resolves to false, but when dividing by false it gets converted to 0, en results in a divide by 0 error.

    So maybe the author was right to expect this kind of behavior from microsoft :p

  • qbolec (unregistered)

    if(the "feature" of encoding false as 0 and true as -1 is documented){ How do they document the behaviour if the value is neither 0 nor -1 ? Do they document what optimizations the compiler can do when "implausible" else clause is detected? }

    also multiplying by True is wrong from the dimensional point of view. You should divide by it! This way it would work for any value they used for true... sadly it won't work for false.a

  • Someone (unregistered)

    I used to use programs like that too. So when I was one of the coders on a very indie game project, I wrote code like this:

    void entity::adjust_entity_hp(int damage) { int oldvalue = hp; if (damage == 0) return; hp -= damage; assert (oldvalue != hp); return; }

  • (cs)

    Y'know, "if" takes a boolean. You have a boolean. There's no need to compare it to the literal true or false.

    if var then
    doThings()
else
    doOtherThings()
end if
  • (cs) in reply to Geoff
    Geoff:
    Truly the real problem with classic VB is error handling. If it was not for the On Error Goto paradigm, which totally destroys the structure of what otherwise might have been well organized quasi OO programs with VB's limited classes.

    I would disagree with this point. "On Error Goto" was not bad, it was just so commonly misused. Think of the "Try Catch Finally" pattern and translate those under the cover jumps to VB6.

    On Error Goto Catch 'Do something Goto Finally :Catch 'Trap your error :Finally 'do some Cleanup

    This works and mimics the Try-Catch-Finally that most people say is just fine. Remember all these are simply Jumps from one code location to another within a particular scope.

    As for your second statement which I didn't quote. Yes VB6 made it far to easy for laymen to mock up something and call themselves programmers, the strength of VB6 was also it's own biggest problem.

  • Some Random Texan (unregistered)

    Hence our propensity to check (FALSE != someBoolean) in C++ when faced with a BOOL type.

    We know for most applications 0 = false, and everything else = true.

    For anything that likes to return with a BOOL to indicate result but also failure, usually there's a define.

    #define API_FAILED -1.

    So, you would say:

    int result; if (API_FAILED == (result = ApiMethod(args))) { // handle failure } else if (result != FALSE) { // result true } else { // result false }

    Good ole days eh?

    Captcha "jugis" - The folk food in some native culture made from the jugular from a rival.

  • Some Random Texan (unregistered) in reply to KattMan
    KattMan:
    I would disagree with this point. "On Error Goto" was not bad, it was just so commonly misused. Think of the "Try Catch Finally" pattern and translate those under the cover jumps to VB6.

    On Error Goto Catch 'Do something Goto Finally :Catch 'Trap your error :Finally 'do some Cleanup

    This works and mimics the Try-Catch-Finally that most people say is just fine. Remember all these are simply Jumps from one code location to another within a particular scope.

    No no no no... Go back 1 space, do not pass go, do not collect $200.

    That only handles an error if one is explicitly stated and/or returned through the stack to this location. Any errors that don't bubble up, don't get caught here.

    Not only that, you have to track layers of errors from any returning program. Oh it's hell.

    try-catch-finally unwinds the stack, so any exception through at any point in the stack jumps to the innermost catch, at which point it can be rethrown to bubble up. Since the exception is an object, it never loses its contextual data.

    Plus, GOTO breaks all logic. When using the stack wisely, one can bake in exit logic, so as the stack unwinds files are automatically closed, etc, even though there was an exception. GOTO skips over all this, leaving any exit logic undone.

    It breaks RAII in C++, and it would totally break garbage collection in .NET if it worked the same way as VB6.0.

    They aren't the same. t-c-f is not a goto.

    CAPTCHA refoveo

  • captcha:modo (unregistered) in reply to Maurits
    Maurits:
    Y'know, "if" takes a boolean. You have a boolean. There's no need to compare it to the literal true or false. 
    if var then
    doThings()
else
    doOtherThings()
end if

    It's true, and that's the advice that’s almost always given (use "if not value" instead of "if value == false"), but I don’t think it's that important.

    When I have to code a conditional my thought process is "now we execute this only if value_x is 3", or "now we execute this only if value_y is not 'foo' ", or "now we execute this only if value_z is true". So isn't it natural to type the code in a similar way every time? Compare:

    if val == 2:
    doStuff()

if val == "Empty":
    doStuff()

if val == [1, 2, 3]:
    doStuff()

if val:
    doStuff()

if val == b"\r\n":
    doStuff()

    Doesn't one of those expressions seem unnecessarily odd?

  • Joshua (unregistered)

    Personally, I'd keep adding that extra else statement, just to amuse anybody else who looks at my code. ;)

  • Ruzinator (unregistered) in reply to Bongo
    Bongo:
    Paul:
    Someone in 2007 already commented that they found this in their VB program.
    You're either a savant or your mind is a infinite junkyard. Remembering a five-year-old (!) comment (!!) found on second page of comments (!!!) ... Now that's something!

    if (savant == true) { msgbox('you are a savant'); } elseif (savant != true) { msgbox('your mind is a infinite junkyard'); } else { msgbox('you know how to use Google'); }

  • (cs) in reply to Some Random Texan
    Some Random Texan:
    KattMan:
    I would disagree with this point. "On Error Goto" was not bad, it was just so commonly misused. Think of the "Try Catch Finally" pattern and translate those under the cover jumps to VB6.

    On Error Goto Catch 'Do something Goto Finally :Catch 'Trap your error :Finally 'do some Cleanup

    This works and mimics the Try-Catch-Finally that most people say is just fine. Remember all these are simply Jumps from one code location to another within a particular scope.

    No no no no... Go back 1 space, do not pass go, do not collect $200.

    That only handles an error if one is explicitly stated and/or returned through the stack to this location. Any errors that don't bubble up, don't get caught here.

    Not only that, you have to track layers of errors from any returning program. Oh it's hell.

    try-catch-finally unwinds the stack, so any exception through at any point in the stack jumps to the innermost catch, at which point it can be rethrown to bubble up. Since the exception is an object, it never loses its contextual data.

    Plus, GOTO breaks all logic. When using the stack wisely, one can bake in exit logic, so as the stack unwinds files are automatically closed, etc, even though there was an exception. GOTO skips over all this, leaving any exit logic undone.

    It breaks RAII in C++, and it would totally break garbage collection in .NET if it worked the same way as VB6.0.

    They aren't the same. t-c-f is not a goto.

    CAPTCHA refoveo

    Are you just trolling or can't you read simple code. Yes Goto on its own does what you say, but put together with the structure I showed allows you to unwind, provides the cleanup, etc. In VB6 you had to hand build the rest of the logic which most did not do, but look VERY carefully, read very slowly what I wrote so your little mind can understand. Goto is a jump, Try causes a jump. When an exception is caught, Goto will jump where you told it to which in this case is the Catch label, the try will automatically jump to its catch. If there is no exception they are both told to make a jump to the finally. The On Error Goto relies on the programmer to provide the proper logic for good error handling, try-catch-finally enforces it, that is the only difference.
  • maarten (unregistered) in reply to pcooper
    pcooper:
    You can run into issues in VB (pre-.NET) if you call into other components (COM or OCX or the like) that don't treat a VB Boolean as an integer that should be -1 or 0. If the component, for instance, stuffs a "1" in there (like a variable Value), then 
    Value = True
    will be true, but 
    Not Value = True
    will also be true, because 
    Not Value
    is the bitwise-not of 1, which is -2, which still isn't 0.
    Done that. Fortunately the interface code was auto-generated, so I only had to adjust the generator.

    Another way to avoid the issue is to leave the VB variable untyped instead making it an explicit Boolean. Fix one bad thing by another...

  • (cs)

    It drives me crazy when people compare booleans with constants. It's like their mind can't process code unless it reads like natural language. And if that's the case then I'd say you're in the wrong profession.

  • Jack (unregistered) in reply to xtremezone
    xtremezone:
    It drives me crazy when people compare booleans with constants. It's like their mind can't process code unless it reads like natural language. And if that's the case then I'd say you're in the wrong profession.
    But, but... that's the whole reason for COBOL. Are you saying all those hordes of COBOL programmers lack some level of professionalism?
  • Ben (unregistered) in reply to Geoff
    Geoff:
    Yes it some pretty epic syntax fails...

    Yes you some pretty epic grammer fails...

    captcha: haero (a japenese hero)

  • lmm (unregistered) in reply to KattMan
    KattMan:

    I would disagree with this point. "On Error Goto" was not bad, it was just so commonly misused. Think of the "Try Catch Finally" pattern and translate those under the cover jumps to VB6.

    That's like saying goto was not bad, it was just so commonly misused.

    Yes, disciplined programmers can use primitive control flow constructs to emulate higher level ones. Programming languages that encourage you to use primitive control flow constructs are still bad outside of very specialized circumstances.

  • (cs) in reply to Frank
    Frank:
    The real WTF here is Visual Basic used together with the term professional programming ...

    so now that you've taken a programming class in high school, are you going to build a website for your neighbor?

    anyways, here's my version:

    MsgBox("you divided by zero, didn't you?")
  • Pista (unregistered) in reply to Duckman
    Duckman:
    This is simply standard practice in Microsoft's trash. Consider one of the most central functions in the Windows API, namely GetMessage. The description is available here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms644936(v=vs.85).aspx

    Notice that it returns the type BOOL, suggesting a boolean value.

    Now read the description of the return value.

    FTFY

  • (cs) in reply to MrBester

    My true is truer than your true.

  • qbolec (unregistered) in reply to captcha:modo
    captcha:modo:
    Compare: 
    if numberOfCats == 2:
    doStuff()

    if cookieJarLabel == "Empty":
doStuff()
    

    if sequence == [1, 2, 3]:
doStuff()
    

    if permissionIsGranted:
doStuff()
    

    if lineEnding == b"\r\n":
doStuff()
    FTFY
  • (cs) in reply to MrBester
    MrBester:
    I'll just leave this here...

    For the lazy, it's a definition of MsoTriStateEnumeration, which is a tri-state Boolean with 5 possible values of which only two are supported. Just let that sink in for a while so you can appreciate the awesome WFTery of it.

    Ternary values are BOOLSHIT!

Leave a comment on “Confessions: Hacker Proof Boolean”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article