I Know, I Know, I Know This Much Is True (…or False)

So today, we’re talking Booleans. Booleans are, as you’re probably aware, one of two states: true or false. This is a beautiful thing… True or false, black or white, left or right, right or wrong, shaken or stirred, scrunch or fold… Sorry… Let’s digress…


Now, with Booleans you have the Logical NOT Operator, represented by our friend, the exclamation point, (the !) What the Logical NOT Operator does is take your object and go all truthy-falsy with it. Basically, the Logical NOT Operator is tasked with finding the logical opposite of whatever your object represents.

So based on the rules I mentioned about what is a truthy value and what is a falsy value we get a series of rules to live by. So let’s take a quick look at Boolean types.

  • If x is true, then !x==false
  • If x is false, then !x==true

This is pretty much the essence of it all… The Logical NOT Operator here acts as a “The Opposite Of…” operator. Opposite of true is false and vice versa… Let’s now push this further to numbers:

  • If x is zero, then !x==true
  • If x is non-zero, then !x==false

Okay, so zero, the only falsy value in the JavaScript natural number system is therefore the only number that will yield true when coerced by the Logical NOT Operator. Subsequently, all other numbers being truthy when coerced by a Logical NOT Operator will yield false. You may recall in one of my previous posts that !0 and !1 have occasionally been used as alternatives to true and false respectively. I will probably go a step further and say that if you were happy to push the boundaries of your code if minimizing or code-golfing, you could technically set specific Booleans to 1 and 0 to represent true and false respectively. Bear in mind the following:

While 0==false and 1==true,
!1===false and !0===true

If you’re scratching your heads about the differences between =, == and ===, let me illustrate it with a very simple set of rules that makes it easy to remember:

  • If you are assigning a variable, you only need the one =
  • If you need to compare values only, you need one more to get ==
  • If you want to compare values and object types, you need one more on top of that to get ===

So, let’s use these rules in a practical example which you can perform in the JavaScript console.

x = “5”; // We’ve set x to a string, typically numeric 5 as a string, NOT the actual number.
x == 5; // You’ll get true

This is because x is compared against the numeric version of the string, forcing the string “5” on the left hand side to be coerced into a numeric 5 to compare against the 5 on the right-hand side. As you’re comparing values, the now-numeric 5 on the left is compared to the existing numeric 5 on the right; 5 is equal to 5… As a result, you’ve got a true statement. But if we try this with === we get something quite different…

x === 5; // You’ll get false

Why do we get false this time around? In this case we’re now adding another level of comparison, we’re comparing against not only value, but object type… We’re comparing a string against a number. As a string is not a number (or vice versa), the === comparison operator fails right there and then, returning false.

So, bear that in mind if you’re thinking of taking some shortcuts with true or false.

So where were we? We’ve looked at Booleans, we’ve looked at numbers… Let’s take a look at strings and the effects of Logical NOT Operators on these:

  • If x is an empty string “”, then !x==true
  • If x is non-empty string like “margarita”, then !x==false

Empty strings are falsy values, and so a Logical NOT Operator on a falsy value will yield true. Consequently, a non-empty string, which is a truthy value when coerced by a Logical NOT Operator will naturally yield false.

Now it’s time for arrays:

  • If x is an empty array [], then !x==false
  • If x is non-empty array like [“margarita”], then !x==false

Herein lies the rub; we may be dealing with an empty array, but it is still a defined array. As a result, it still has value, and is thus truthy, thus ![] will yield false.

Bear in mind that an array with a falsy value as its only element (such as [“”] or [0]) is still a non-empty array, and like all non-empty arrays, will yield false when coerced by a Logical NOT Operator.

Now, back to objects… The truthy little buggers that they are. An object is truthy regardless of whether it is empty or non-empty. Case in point:

  • If x is an empty object {}, then !x==false
  • If x is non-empty array like [“pizza”:”supreme”], then !x==false

So, put simply, JavaScript object types don’t really respond well to change when it comes to coercing them to a Boolean with a Logical NOT Operator…

So, what do we do about the other objects – the dates, the functions, the regular expressions? We can test those out too… So, let’s take a quick look at Dates

!(new Date) // returns false

Why has it returned false? Date objects are truthy. And thus a Logical NOT Operator coercing a truthy value will result in false.

How about regular expressions? They’re truthy as well… Put a Logical NOT Operator in front of a truthy value and you will get false:

!/tic|tac|toe/ // returns false

Lastly, functions… Functions when coerced by a Logical NOT Operator act similarly to how functions behave when coerced by a unary or negation operator, the end result is basically what you get after the operator has acted on the return value of the function. If a function’s return value is truthy, the Logical Not Operator acting upon the function will result in false; whereas if a function’s return value is falsy, the Logical Not Operator acting upon the function will result in true.

Case in point: x = function(y) { return y + 1;}

  • !x == false
    is defined, therefore truthy, thus !x is false.
  • !x(-1) == true
    x(-1) == 0, therefore falsy, thus !x(-1) is true.
  • !x(0) == false
    x(0) == 1, therefore truthy, thus !x(0) is false.

Let’s try a function with no return value: y = function(z) { var x = 17;}

  • !y == false
    is still defined, therefore truthy, thus !y is false.
  • !y(27) == true
    There is no return value for the function, as y(27) returns undefined. Undefined is a falsy value, as a result, !y(27) is true.

So there’s the Logical NOT Operator and how Booleans can be coerced from other objects using it. The final operator of focus is the concatenation operator, which funnily enough is also represented by the + character. I’ll address the concatenation operator in my next post. Stay tuned!

Unary and Negation Operators Part 4 – Dates, Functions and Regular Expressions

I can only promise this post will be quick and painless… Kinda like ripping off a Band-Aid…

There were three final object types in JavaScript that hadn’t been taken into account with regards to Unary and Negation Operators; they are dates, functions and regular expressions… Let’s kick it off with dates…

Thing is with the Date object… One needs to declare a new instance before anything can really be done with it.

+Date // result is NaN

+(new Date) // result at time of running was 1438551674445.000000

Running the latter statement as +new Date works just as well, but for two less characters (see my upcoming post on code golf). But the result is basically the number of milliseconds since Epoch (January 1, 1970 00:00:00) began. So in essence you have a very large number, + and basically make it positive and negative. And that’s all there is with Unary and Negation Operators and date objects.

Next, I’m skipping to regular expressions as functions basically are capable of returning anything, including other functions… But we won’t be going into that… Regular expressions… these are the lovely things that look a bit like this:


This was part of my entry for distinguishing regions of Italy against American states. Regular expressions are great for matching against certain sets of words, like in the example I’ve linked above. What they can’t do however, is translate well to numbers… Actually, they suck at it… Big time… Take our lovely example from the paragraph or so before…

x = /at|gn|mp|sc|-|’|((zi?|t)o|[hts]e|[lrd]ia)$/g; // x stores the RegExp
+x // result is NaN
-x // result is also NaN

Hmmm… what if, like strings, they were completely numeric? Still doesn’t work, told you before, regular expressions suck at this… they’re great for what they can do, but being coerced into numbers is not one of them:

x = /3456/; // Stored the regular expression of /3456/ to x
+x // NaN… still nothing…
-x // NaN… also nothing…

So, regular expressions are therefore pretty useless when it comes to coercing them into numbers. They’re great for other things, but just not for converting into numbers. So let’s put that to rest…

Finally, functions… Now I will assume that if you’ve been programming for some time that you know how a function works…

x = function (y) { return y*2; }

Simple function, number goes in, double the number goes out.

Now, as you’re dealing with something that provides a return value in this particular instance, +x(5) or -x(17) will provide a response that is basically the Unary or Negation Operator working on the return value. In the case of +x(5), this will return +(10) which will then become 10. -x(17) will return -(34) which will then become -34. If the return value of a function was a string, the Unary or Negation Operator would interact with that to provide the final result, and so on.

So general rule is, if a Unary or Negation Operator is coercing a function, the final product from this coercion is the result of the Unary or Negation Operator acting on the function’s return value.

What if there’s no return value? Let’s test it out with an example:

y = function() { var x = “42”;}

Even expecting a return value on this function is unheard of, and the JavaScript console responds in kind with undefined. Well, when you think about it, that makes a lot of sense. We haven’t defined a return value on y() and therefore the undefined is definitely appropriate!

So bearing this in mind, using a Unary or Negation Operator on a function that has no return value is the same as trying to coerce undefined with a Unary or Negation Operator; and as a result in either case, the result is our lovely friend NaN.

So there’s Unary and Negation Operators sorted. In my next post I’ll move onto other operators, and hopefully provide a quicker run-down on how these other operators affect JavaScript object types.

Until then!