!(test1 == test2)

!(test1 == test2)
test1 != test2
which one are you Sup Forums?

First one, is not aesthetic, but you can't tell is a negation right away

i wouldn't name my variables test
also the first one is retarded

!(!test1 != !test2)

if (test1) {
if (test2) {
return
}
}
if (!test1) {
if (!test2) {
return
}
}
// code goes here

whichever reads more naturally in context

>equality is more natural than inequality
As a mathematician I just plain can't wrap my head around this. Did Java whip you down with its .equals shit or something?

>Did Java whip you down with its .equals shit or something?
please refrain from throwing around jargon you don't know.
the .equals is an instance method inside a particular class used to compare the fields of two object in that class. == cannot be used to check equality of two objects' states, unless you want to check if the pointers are both referring to the same object.

>jargon
How bout not using WORDS you don't know? A particular method is nor jargon. The word "method" is jargon.

You're one-upping poorly. Not only did you entirely miss MY point (the point where by hiding complexity from the user, it makes the user start thinking unintuitively), but the points you make are both not relevant to anything and honestly not even that true. .equals is just a method. Inherently it has nothing to do with comparing fields, it's an abstract idea of equality to be implemented by the Object.

>== cannot be used to check equality of two objects' states
That's because the Java devs think operator overloading is bad. They can go fuck themselves.

test1 test2

second, readable code is important

The latter is almost always more correct, even if for the trivial point that shouldn't even matter which is that in languages that support operator overloading, a != b could in fact be different than a == b.

It's more of that you couldn't do that without breaking backwards compatibility with existing code. However, I think at the very least they could allow it for greater/less than as you can only use those on primitive types currently.

2nd
Wouldn't even think to use the first

Who told you were comparing bools you dumb nigger

(not? (eq? test1 test2))

!(A && B)
!A || !B

which one are you Sup Forums?

This checks for equality

I simply wrap both in a range then cast std::mismatch on the std::negate'd std::equals_to.

>he doesn't know De Morgan's law to know which expression is the simplified one

who the fuck does first one

My nigga

if ((test1 == test2) == !true)

memcmp(&test1, &test2, sizeof(test1));

Wtf is this?

Second has less characters overall

this

>!(test1 == test2)
Do people actually do this?

#DEFINE ifn't(x) (if !x)

ifn't (test1 == test2)

This is so awful I'm not even sure it's bait

Either a != b or !a.equals(b) if that's not available.

Please never touch a keyboard again.

I've seen someone did this:

if(test1 == true)
return true;
else
return false;

Does
if !(test1 == test2) {
//code
}
Even work? It's possible that it would vary depending on the language.
I wouldn't do it that way though. While it is still doing the same thing it is more obvious the other way.

If we carry it further, would you do
test1 < test2
or
!(test1 >= test2)
They both do the same thing, and you could argue that if you want to easily reverse the operation the second one is faster, just remove the exclamation mark, but I could see it being a bitch in troubleshooting.

bool.isEqual(test1,test2);

This is valid practice in JavaScript

”0” == true ? true : false // returns false
”0” ? true : false // returns true
[] == true ? true : false // returns false
[] ? true : false // returns true

if True
vs.
if NOT False

SQL

depends on my mood

>Does ... even work?
Why shouldn't it?

>the second one is faster
Don't waste your time thinking about one or two cpu cycles

Boolean is binary, so it's the same thing.

I wasn't talking about processing speed but rather if you want to change your code so that it does the reverse it is one change, just remove the bang.

test1 ^ test2

Are you a brainlet CS major?