Comment On Boolean Integers

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.

Bitwise math. I love it!

Wow...just wow...

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

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

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.

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

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

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 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....

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.

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.

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".

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

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)

TORWTF is that crazy code indentation....

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

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.

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.

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

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

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

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.

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

Actually, this implementation looks "Pretty Simple".

Looks like Java to me.

Which is your favorite Bit?

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

I've always preferred to call it D Flat.

clbuttic c-pound code!

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.

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

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.

DeLos:

clbuttic c-pound code!

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

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

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.

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;
}

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...

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?

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.

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.

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?

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.

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

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.

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.

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.
}

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.

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