It has to be done.

Fixing QA bugs.

Number 1176563 shows even on this

Did someone say hacks?

return !number&1;

@Lensflare With this being unreadable as fuck, does it at least bring performance benefits over the expected "return number % 2 === 0"?

@kamen probably not.
% requires integer devision and & requires bitwise "and".
This should be one basic operation on most of the hardware.

On the other hand, you have an extra comparison with 0.
But then again, it could be optimized away.

@kamen

@Lensflare

sometimes code that is unreadable as fuck is also sexy as fuck. If @Lensflare was a woman she'd be my programming crush right now

@Hazarth 😄
Yes. It’s beautiful but I’d never use it in production code of course.
(It can’t handle the beauty)

Couldn't you have just installed a npm package for this 😈

... could you explain more context on this? Is this a joke? Did people read write this?

@Lensflare what's !number? It's not valid syntax in C# (which I'm pretty sure is the language of the snippet above)

@bananaerror yeah I was cheating a bit.
In many languages (like C), an integer that is not zero evaluates to true implicitly. ! is of course the not-operator.

@Lensflare Ahhh okay it all makes sense now.

@eo2875 > "Did people write this?"

The previous administration here had a hard-on for achieving 100% code coverage, so some projects had hundreds of unit tests that looked like ..

var dto = new MyDataTransferObject();

dto.SomeProperty = 3;

Assert.IsTrue(dto.SomeProperty == 3);

With individual tests for *every* property.

Seeing code like this in production doesn't surprise me that much. Saddens..but doesn't surprise.

Nuke it from the orbit.