My team lead thinks using a double Not operator in javascript is too confusing and not readable.

Opinions?

Why would you use a double negation? Looks like superfluous code, which alone is reason enough to avoid it.

Convert value type to true boolean so that a method that is typescript annotated to return a boolean actually does.

@craig939393 Looks like bypassing the type system through casts. If that's the case, the underlying code should be fixed.

@24th-Dragon can you give an example please?

Are you actually bypassing the type system? Well, it's JS, the type system is best dealt with by bypassing it. I'd suggest creating a tob function for this purpose, it's probably more readable that way.

Unless you show why you would use a double not I'm just gonna agree with the rest of the thread and say fucking don't

@inaba There's only one reason to use a double not in JS.

@inaba calm down xD

For instance you might have an interface with a method that has a boolean return type that forms some of your overall code design. Think guards in the angular routing system.

So then to ensure that a boolean gets returned, because it is possible that if relying on the type system and a boolean is actually not being returned there might be a problem that is hard to pinpoint later, instead of another value when the boolean is dependant on a property on an object, or any value being present I see 2 choices.

Return Thing ! == undefined & & thing ! == null

Or

Return !! Thing

The not operator approach I like because people often forget to do both the null and undefined checks and it causes bugs sometimes where I work.

Wtf, yes of course that's bullshit. Ever heard of Boolean(val)

@nitwhiz nope :D

@halfflat I'm still using that in C for static assert macros, but that's a bit of a hack and shoved away into a macro definition so that it doesn't appear in actual code.

Now I have seen the Boolean function exists that's the answer I guess

Thanks for the answers from the people that aren't rude, the rest on this should grow up

@craig939393 Though the Boolean() thing is also dirty IMO. A Boolean should only take the result of comparisons or true/false directly.

I'd write a proper comparison and let the build chain take care of optimising that to a shorthand.

@craig939393 I hope you don't mean me. If so, i apologize (really). For me it was totally natural to consider Boolean(), exactly like String() or parseInt().

@nitwhiz no worries. Thanks though :)

I have never used the primitive functions before. I'll have to go learn about them.

Thanks again.

@craig939393 "might" is all well and good but why are you actually doing it? How are you getting the object? Since you're using typescript you have the ability to force something to be either something or null, so you wouldn't have to check for undefined anyway, and if you're getting it from some list why not just use some then?

IMO if your team thinks it's too confusing and not readable, you probably have a hard job dealing with those clowns.

I remember being confused by it the very first time I saw it. I asked someone "what's this?", heard the answer, thought "that makes sense", and have never thought twice about it since. It's clear and concise.

Oh and it's way faster than anything else (not that that usually matters).

First time I came across !!x I was put off, but then knowing x could be undefined or NaN depending on its use, it became clear what was being achieved with this.

I don't write it myself, but I don't hold a grudge over you if you do.

@Gorlami I know, that's the point of an implicit cast. It's just that casts generally suck.

I use it sometimes, especially dealing with data from API, because who knows what some new BE team member decides an endpoint should return..

The best way to solve it however is to provide developers with a function similar to PHP's empty($var)

He's right

Your lead is a wise person