There are two kinds of people:
those who write
if foo.isBar() {
foo.setBar(false)
}
else {
foo.setBar(true)
}

Vs
those who write
foo.setBar(!foo.isBar())

Only good programmers will understand😢😊

And then the manager will ask you not to write in such way to preserve readability adding to the frustration

@razorstone to which you respond: "stop hiring so many dumbasses!"

Or you could do the cleaner version and go with:
notBar = !foo.isBar();
foo.setBar(notBar);

Which one is best practice?
Writing readable and long code, or writing short and less readable code.

I would think, that the short solution is a common thing. No need to use the first one.

I am different still: I put my conditions in brackets

A really good programmer has foo.toggleBar() for this case.😛

@Ashkin haha well said

@saifat29 best practice would be to put the simple short hand and clever logic into a function and use that but in this case there is already a function for the job.

which one has the better performance?

@vhoyer interesting question that... not something you would really notice with such a little task.
One of the biggest differences is that the if / else will stop evaluating upon returning true so it is a matter of the operations required to invert the state.

@vhoyer its
cmp, stor, jump, set, jump
vs
xor, stor, jump, set, jump
I honestly think cmp is expenisve enough to make the second thing faster..
(I ignored the jumps for isbar, they shouldn't play a role)

I think you are wrong. I'm a bad programmer and I understood

@saifat29 The short version is actually more readable to anyone who understands what a boolean is.

The first version is more of a sort of explanation to those who aren't familiar with the language or its logic operators. Such explanations belong in tutorials about the language and should not be repeated in code written in the language.

Having said that, I always prefer the simplest code possible, but adding redundant verbosity is not the same as simplifying.

@daintycode read my mind...

@daintycode
👌

@Sweenu then don't call yourself bad. You haven't seen bad ones yet!

@droidshere That might be it haha

@Sweenu write down everything you know and you may surprise yourself

In my readable code is more important (until working on a time critical situation/ software) since most software end up being the responsibility of someone else...

But, in the above case, the shorter one looks better, but probably, even works better.. (not sure, ask me in the morning since I am nearly been awake for more than 20 hours and my brain might soon go into hibernation)...

In my opinion, to make it readable, we should place the condition into another Boolean variable...

Like someone else suggested on this rant... Let me look at... For a moment... Already told you the reason for my clumsiness..

Yeah, like @pmarius suggested...

@pmarius "notBar = !foo.isBar();"

That roughly reads like "notBar is not isBar". What's the point of that?

@Grumpy That was a simple case, but in practice there are several conditions for if statements and instead of putting them all in the IF and chaining them there, you can easily declare them just before it.
For example, tell me what can you as an outsider read faster:

if (object.getMainContainer().isSet(randomvar) || (randomVar.length > 0) || ((randomVar.length%2)==1)) {
...
}

versus

varSet = object.getMainContainer().isSet(randomvar);
atLeastOnce = randomVar.length > 0;
oddCount = (randomVar.length%2)==1;

if (varSet || atLeastOnce || oddCount) {
...
}

The second version gives more information to the next guy reading it. Keep in mind that in practice there might be even more conditions.

@pmarius That was a good example and in cases like that, I totally agree with you.

@qbalsdon Yes, but that often vary from language to language. Some languages don't need that.

I'd write that as

foo.setBar (foo.isBar() ? false : true);

or

foo.setBar (foo.isBar() == false)

depending on what really those methods are.

I expect a modern compiler to be smart enough to avoid redundant comparisons and simply replace that with a NOT

Or maybe ´foo.toggleBar()´? why is nobody suggesting this?

@rephiscorth Because that could be the name of the function containing the code we discuss, but we're discussing the code itself. ;-)

@Grumpy if discussing the implemontation, it should be `this.bar = ! this.bar`. No need to call the public getter inside the class

@rephiscorth also it was already suggested :)

If(is_Purfect() == false) console.log ("who cares it works");

Write in the former style then R# it.

<alt>+<enter> = pick option that maks your code look like it was written a smart arse.