• Anonymous (unregistered)

    I'm always amazed at the number of people who don't understand bitwise operators in C. Any type of embedded GPIO practically requires them.

  • (cs)

    Bitwise math. I love it!

  • Christian (unregistered)

    Wow...just wow...

  • (cs)

    I bet he had nightmares about having to add another 'bit'.

  • Michael (unregistered)

    If the code REALLY looks like that, there's another WTF hidden: It literally is 1111111 (decimal), not binary 1111111 aka 127.

  • (cs) in reply to Michael
    Michael:
    If the code REALLY looks like that, there's another WTF hidden: It literally is 1111111 (decimal), not binary 1111111 aka 127.
    Your powers of observation are incredible.
  • (cs)

    That first one is actually octal, right? It is in C/C++, anyway.

  • (cs) in reply to Michael
    Michael:
    If the code REALLY looks like that, there's another WTF hidden: It literally is 1111111 (decimal), not binary 1111111 aka 127.

    That is actually a feature. It allows you to REALLY make sure you are searching for an lastnameby passing in a 9000000

  • (cs) in reply to Michael
    Michael:
    If the code REALLY looks like that, there's another WTF hidden: It literally is 1111111 (decimal), not binary 1111111 aka 127

    If only it were that simple. All the numbers with a leading one are actually in decimal--but leading zeros? That's octal, baby!

  • Burninator (unregistered)

    This is the first code in a month or two that's made me actually want to gouge my eyes out in disbelief.

    The fact that he attempted to use a bitmask but had to make a constant variable for each possible combination of bits that he would use, OUGHT to tell him something....

  • Jens (unregistered)

    He he, Speak of the devil! I'm making use of a bit array myself for something im working on right now.

    Though i'm opting to use the bitwise operators for accessing it, and i think i'm going to the skip storing every possible combination as a constant (who's decimal represetation resembles the binary representation of arra).

    Great that he actually has booleans for everything allready ... but insists on setting the contants anyway.

  • cthulhu (unregistered)

    There's nothing essentially wrong with doing it like this, in fact in some situations it is to be prefered.

    You get finer grained control over the business logic if you can handle specific combinations seperately. You can, for example, scroll down to the elseif block that handles the DOB-email-name combination and make it a Special Case with special behavior. It makes it a lot easier to refactor.

    That's not so easy if you just obfuscate it all as a load of bits and masks which by definition have no meta-data attached.

  • Anon (unregistered)

    Because of the mix between octal and decimal, I'm guessing that's why he did this. Something wasn't working by using bitwise operators correctly (because his numbers were wrong), so he came up with this cockamamy scheme to get it to work.

  • Berislav (unregistered)

    Wait a second -- why is the result variable of all those if's called matchPattern? It couldn't be that they perform a regexp comparison somewhere down the road, could it? If this is so, the WTF should be titled "Boolean Integer Strings".

  • this webcomic is a wtf (unregistered) in reply to Michael
    Michael:
    If the code REALLY looks like that, there's another WTF hidden: It literally is 1111111 (decimal), not binary 1111111 aka 127.

    This is actually very nice, we can then change the value to a string, then test for the condition with a simple mid(str(integerflagholder),positiontotest,1). You can't do neat stuff like that with some crazy ass binary bit flipper.

  • yer mom (unregistered)

    After defining 20 of these "bit patterns" he probably thought "Screw this", and left out the other 107.

  • earl (unregistered) in reply to Welbog

    Well, at least that explains why the programmer could not use bitwise operators:

    MATCH_LNAME_DOB | MATCH_EMAIL_ONLY != MATCH_LNAME_DOB_EMAIL 0x10C8E0|0x3E8 != 0x10CCC8 0x10CBE8 != 0x10CCC8

    1100000|0001000 = 1100776

    So it makes perfect sense why the binary operators where not used: they just would not work.

    (and by the looks of it, that is Java)

  • (cs)

    TORWTF is that crazy code indentation....

  • Pyro (unregistered)

    There are exactly 10 types of people in the world: those who understand binary and those who don't :)

  • BrianJ (unregistered) in reply to gekko
    gekko:
    Michael:
    If the code REALLY looks like that, there's another WTF hidden: It literally is 1111111 (decimal), not binary 1111111 aka 127

    If only it were that simple. All the numbers with a leading one are actually in decimal--but leading zeros? That's octal, baby!

    This looks like C#. C# does not have octal literals. So all these numbers are decimals.

  • Harry (unregistered) in reply to Pyro
    Pyro:
    There are exactly 10 types of people in the world: those who understand binary and those who don't :)

    There are exactly three types of people in the world. Those that understand true and false and those that don't.

  • sweavo (unregistered) in reply to Pyro
    Pyro:
    There are exactly 10 types of people in the world: those who understand binary and those who don't :)

    And those who know about ternary

  • yer mom (unregistered) in reply to BrianJ

    There's no final in C Pou... Sharp

  • John Doe (unregistered)

    In this case using XML would really be a better solution... (No matter what way!)

  • krupa (unregistered)

    Let me count the ways that code is bad. Oh wait, I only have an integer to store the total and I see eight things. Shit.

  • tgies (unregistered) in reply to cthulhu
    cthulhu:
    There's nothing essentially wrong with doing it like this, in fact in some situations it is to be prefered.

    You get finer grained control over the business logic if you can handle specific combinations seperately. You can, for example, scroll down to the elseif block that handles the DOB-email-name combination and make it a Special Case with special behavior. It makes it a lot easier to refactor.

    That's not so easy if you just obfuscate it all as a load of bits and masks which by definition have no meta-data attached.

    look how dumb you are

  • BlueCollarAstronaut (unregistered)

    Actually, this implementation looks "Pretty Simple".

  • (cs)

    Looks like Java to me.

    Which is your favorite Bit?

  • keanpedersen (unregistered) in reply to BrianJ

    The code is in Java, which does have octal literals.

  • Anon E. Muss (unregistered) in reply to yer mom

    I've always preferred to call it D Flat.

  • (cs)

    clbuttic c-pound code!

  • Anonymouse (unregistered)

    This is clearly a case of Cargo Cult design. He saw the bitfield method used somewhere, heard it was the right thing to do, and tried to implement it. Without the appropriate background in boolean mathematics or software theory. And then made a complete botch of it.

    Since C doesn't usually (outside of certain embedded compilers) support raw binary numbers, most people use octal or hex for constants. Then you get a nice string of 0x0001, 0x0002, 0x0004, 0x0008, 0x0010 etc.

  • Emphyrio (unregistered)

    TRWTF is that the equals signs are not lined up in the constant definitions.

  • (cs)

    Sweet Lord.

    It doesn't matter what language it is. Given that you need to track that much information, the combinations give 2^7=128 possible combinations. Setting a constant for each possible combination is just silly.

    Structure the code s.t. you deal with the fields as little as possible.

    if 
(hasLastName && hasDob && hasFirstName && hasEmail 
             && hasRefNo && hasTelNo && hasAddr) {
    DO SOMETHING; 
    } else if 
....

    Setting a bunch of constants that you have to remember later is a foolish waste of resources. (The programmmer's time, mostly)

    Later on, you'll have to have something like

    if 
(MATCH_LNAME_DOB_FNAME_EMAIL_REFNO_TELNO_ADDR) {
    
    Do Something; 
    } else if 
....

    How is that better than the setting of flags in the first place?

    Finally, what if I have email & address, but not the last name? Shiat.

  • Anonymous Coward (unregistered) in reply to DeLos
    DeLos:
    clbuttic c-pound code!

    It's Java. C# has no final keyword.

  • (cs) in reply to tgies
    tgies:
    cthulhu:
    There's nothing essentially wrong with doing it like this, in fact in some situations it is to be prefered.

    You get finer grained control over the business logic if you can handle specific combinations seperately. You can, for example, scroll down to the elseif block that handles the DOB-email-name combination and make it a Special Case with special behavior. It makes it a lot easier to refactor.

    That's not so easy if you just obfuscate it all as a load of bits and masks which by definition have no meta-data attached.

    look how dumb you are

    you should all video in your bitwise operations

  • (cs) in reply to Pyro
    Pyro:
    There are exactly 10 types of people in the world: those who understand binary and those who don't :)

    There are 2 types of commenters, those that are able to create original humor and those that can only parrot things that were funny five years ago.

  • Alan (unregistered) in reply to cthulhu
    cthulhu:
    There's nothing essentially wrong with doing it like this, in fact in some situations it is to be prefered.
    There is so much wrong with that, i don't know where to start. There is absolutely no reason to define all those extra matches, only 7 are required.

    What should be used here is a bitfield, no question about it, but not in the way he implemented it. Let me psuedo code a much better one in C#:

    public enum MatchPattern { None = 0; FirstName = 1 << 0; LastName = 1 << 1 Email = 1 << 2; ... ... }

    public MatchPattern Match () { MatchPattern p = MatchPattern.None; if (hasLastName) p = p | MatchPattern.LastName; if (hasFirstName) p = p | MatchPattern.FirstName; if (hasEmail) p = p | MatchPattern.Email; return p; }

  • Schnolle (unregistered) in reply to cthulhu

    Oh, sure. All you have to do is to find the special case among the 128 different cases in this motherhuge if statement reaching over about three dozen pages, which is MUCH easier than just have a separate statement covering all the actual special cases after the assignment or whatever...

  • (cs) in reply to Schnolle

    Aside from the fact that he's using decimal numbers instead of bitstrings, isn't THIS TRWTF:

    " You have only a single integer to represent them. "

    Is he writing for the VIC-20 or something?

  • mack (unregistered) in reply to cthulhu

    anyone who doesn't think that this code is a piece of crap should be slapped across the face with a keyboard. I suppose the author of this code, as well as this comment, have never heard of something called an enumeration.

    If you are setting your program up to have multiple special cases then you are setting your program up wrong.

  • (cs) in reply to sweavo
    sweavo:
    Pyro:
    There are exactly 10 types of people in the world: those who understand binary and those who don't :)

    And those who know about ternary

    And those who have social anxiety disorder.

    So really there are 4 (decimal) or 100 (binary) kinds of people in the world.

  • (cs) in reply to Pyro

    In 30 years of programming, I can honestly say I've never seen anyone use mixed decimal bitflags (octal yes, hex yes but never decimal).

    Maybe this guy just didn't understand the difference?

  • (cs)

    This is the worst kind of code. Using a bitmask isn't super-advanced, but it does take a certain degree of cleverness to apply it appropriately. So when I see code like that, I usually think that the programmer knew what he/she was doing and I spend time reverse engineering and trying to rationalize it when I should just throw it out the window.

    Horrible code masquerading as clever code is your enemy.

  • lagzor (unregistered)

    the real wtf is that the featured comments are even bigger wtfs than the article.

  • Kyle (unregistered) in reply to this webcomic is a wtf
    this webcomic is a wtf:
    Michael:
    If the code REALLY looks like that, there's another WTF hidden: It literally is 1111111 (decimal), not binary 1111111 aka 127.

    This is actually very nice, we can then change the value to a string, then test for the condition with a simple mid(str(integerflagholder),positiontotest,1). You can't do neat stuff like that with some crazy ass binary bit flipper.

    No you can't, because (((1 << positiontotest) & integerflagholder) != 0) is too long.

  • diebitfieldsdie (unregistered) in reply to Alan
    Alan:
    What should be used here is a bitfield, no question about it, but not in the way he implemented it.

    I question that. Unless you are working with limited hardware or bandwidth, there is no reason to try to cram 8 boolean conditions into a single byte. It will only lead to obfuscation and wtfery. There are several alternative solutions involving data structures all the way from enums to classes, all of which involve no more overhead than the original wtf here, and all of which are far more maintainable and less bug-prone.

    I would likely just set independent bools and check them in the if statements directly, which has the benefits of adding metadata (variable names) to the conditions, requires coding only the number of cases you actually need, and the logic being immediately readable by the poor sod who has to debug it later.

  • Kyle (unregistered) in reply to cthulhu
    cthulhu:
    There's nothing essentially wrong with doing it like this, in fact in some situations it is to be prefered.

    You get finer grained control over the business logic if you can handle specific combinations seperately. You can, for example, scroll down to the elseif block that handles the DOB-email-name combination and make it a Special Case with special behavior. It makes it a lot easier to refactor.

    That's not so easy if you just obfuscate it all as a load of bits and masks which by definition have no meta-data attached.

    Why yes in fact, it is.

    if (specialcase) { } else { //use bitmaps here. }

  • (cs) in reply to cthulhu
    cthulhu:
    There's nothing essentially wrong with doing it like this, in fact in some situations it is to be prefered.

    You get finer grained control over the business logic if you can handle specific combinations seperately. You can, for example, scroll down to the elseif block that handles the DOB-email-name combination and make it a Special Case with special behavior. It makes it a lot easier to refactor.

    That's not so easy if you just obfuscate it all as a load of bits and masks which by definition have no meta-data attached.

    Fail.

  • (cs) in reply to lagzor

    Well if they are going to be highlighting the troll posts, I think its time to quit reading this site.

Leave a comment on “Boolean Integers”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article