DEV Community: Elise Marie LaBonte

A Controversial Case for Double Equality

Elise Marie LaBonte — Thu, 10 Feb 2022 21:59:47 +0000

Maybe this is a common experience in web dev bootcamps.
You're stuck in lecture, trying to stay present while a fire hose of information is blasted at you. You've missed the last six things the instructor has said and then you catch the one thing that's seemed simple this whole time: "Just use triple equality every time. Double equality will inevitably cause bugs".
Man, it's refreshing to have strict rules that I don't need to understand.

I've been using triple equality in my code ever since. It can be a beautiful thing to behold. So demanding. So pushy. Just look at it.
console.log(12+14===37-11) ** >> true **

I will admit at the same time that this feels intellectually lazy. And when things feel intellectually lazy, it's usually an omen that relevant bugs will turn their ugly head when you're least expecting.

The distinction that I always hear between abstract (aka "double") and strict (aka "triple") equality in JS is that triple equality checks the data type while double equality does not, thus making triple equality more useful.
It turns out that that is not accurate.

below is how each comparison process takes place according to the JS spec.

abstract/double equality:

strict/triple equality:

As you can see, the very first step for both processes is to check types. The distinction between the two is that strict equality immediately returns false if the types do not match, whereas abstract equality continues comparisons by performing a series of coercions on the data.

in effect:
var twentySIX = "26" console.log(26 == twentySix)
the above code (using abstract equality) would return true, whereas
var twentySIX = "26" console.log(26 === twentySix)
the above code (using strict equality) would return false.

Why does this really matter?
Using strict equality essentially implies that the author does not know (or does not care) what types of data are being passed in...

But shouldn't we care?

Kyle Simpson, author of You Don't Know JS: Scope & Closures has a ten hour course on Javascript Deep Foundations that covers this subject where he argues that Javascript authors should very much care about it. Furthermore, he argues that the default should never be to use strict equality.

While I highly recommend watching his course, here is the spark notes argument:

the number of cases where abstract equality and strict equality differ are few enough in kind that they should be considered corner cases.
abstract/double equality communicates to future readers that you, as the author, are confident in the data types being passed in.
code that knows exactly the types being passed into it is always, as a rule, better code.
not knowing types means not being confident in your code. when put that way, it is clear that this should be a rarity, not the default mindset.
== is more readable than ===, therefore making the code overall more readable.

With all of that said, when should strict equality be used?
Again, here is what Kyle Simpson has to say on that:

before the triple equal is to be used, the author should first attempt to refactor their code in a way that they can be confident about types.
not knowing types is equivalent to assuming type conversion/coercion is happening, in which case you must be defensive in your code, thus necessitating strict equality.

The differences between strict and abstract equality can seem minute when writing code, and the case for defaulting to abstract is certainly not a popular one. Will hobby projects and simpler applications suffer over this?
Probably not.

However, professionally written code and bug-free apps are goals that we should all have as code writers. It's the mindset of a curious developer to thoroughly understand and have educated opinions on the methods and mechanics of your code. And as dull as reading the spec can be, it's good practice to check how your mental model of your code shapes up against what really happens under-the-hood when it executes.

Whether you agree with Kyle Simpson's stance on strict-versus-abstract equality or not, it's absolutely worth while to watch his courses. Watching long-time industry professionals discuss their approach (especially when it's controversial) is a great way to discover blind-spots in our own knowledge base.

check out the JS spec here
check out Kyle Simpson's course list on Front End Masters here

Cracking into Regex

Elise Marie LaBonte — Fri, 04 Feb 2022 17:58:09 +0000

Regex (regular expressions) are snippets of code used to search for specific characters. In this tutorial, we'll explore how to write regex using an example I've written which passes latitude and but not longitude.

Regex is one of those topics that makes my eyes glaze over as soon as I look at the docs, but I can also say that there are few things more satisfying than having a successfully written block of regex. Not only can it shorten the amount of JS that you write in your functions, there are just some things that can't be done without it.

Below is a regex which will pass latitude written in a variety of different formats, but which will not pass longitude.

/(?<coordinates>\d{2}[d°\.\-]\s?\d{2}[m'\.\-]\s?\d{2}[s\"\.\- ]\s?)(?<hemisphere>(north)|(south)|(n|s))$/i

Here is a break down of this regex.

<coordinates> and <hemisphere> both mark the "names" of their respective blocks within the regex.

The first group, named 'coordinates' matches two digits, directly followed by a specified symbol, followed by a whitespace, followed by the same pattern repeated twice. The only difference between each repetition of this pattern is that the symbol following the digits can be a D in the first (degrees), an M in the second (minutes), and a S in the third (seconds). The second group, named 'hemisphere' matches different options that signify the southern or northern hemisphere.

Navigate through the table of contents to read an explanation of each piece of this regex.

Anchors
Quantifiers
Grouping Constructs
Bracket Expressions
Character Classes
The OR Operator
Flags
Character Escapes

Regex Components

Anchors

Anchors specify where the engine searches. They are special characters that do not match any characters being searched. A ^ is used just before a character/group to specify that it comes at the beginning of an expression, while a $ is used directly following a character/group to specify that it comes at the end of an expression.

In our example code, the \$ at the very end means that our coordinate must end in one of the following options: n, N, s, S, 'north', 'south', 'North', 'South'.
ex.
((north)|(south)|(n|s))$

This ensures two parameters:

a coordinate which does not specify a hemisphere will not match.
a coordinate which ends in an "east/west" (i.e. longitude) signifying hemisphere will not match. ### Quantifiers Quantifiers describe how may of a certain character to search for in a group. The following symbols are used as quantifiers: * (search for zero or more occurrences), + (search for one or more occurrences), ? (search for zero or one occurrence), {n} (search for n number of occurrences), {n, z} (search for occurrences numbering between n and z).

In our example, we used quantifiers to specify the number of digits at the degree, minute, and second position in the latitude. (This also aids us in ruling out some longitude inputs, since longitude is often expressed with a three-digit degree.)
ex.
\d{2}

Grouping Constructs

Items that match a search can be grouped and named. Parentheses help us with this. A name is not necessary for a group, but it can be specified by using the following syntax: (?abc). If no name is specified, the groups will be named numerically by default.

In our example code, the first group is named 'coordinates' while the second is named 'hemisphere'.
ex.
(?\<coordinates\>.....)

(?\<hemisphere\>.....)

Bracket Expressions

Bracket expressions treat the items inside as individual characters. The engine matches any individual character within the brackets. So, a search of [fc]at would match the words fat and cat, but not sat.

In our example code, we use brackets to match some of the different characters that are used to express longitude, as well as some of the different ways that a north/south hemisphere can be expressed.

ex.
[dD°\.\-\s]

Character Classes

Character classes are indicated using a bracket expression. They can specify a single character or a range of characters. For example, [a-j] would match any letters between a and j in the alphabet, and [2-7] would match any digits between 2 and 7.

The OR Operator

A '|' can be used to match expressions on either side within a set of parentheses. A single character or multiple can be compared here.

In our example code, we use the OR Operator to specify a hemisphere from a few different options.
ex.
(north)|(south)|(n|s))

Flags

Flags are used at the end of a regex to specify search options. The syntax for flags is a '/' followed by one of the following options: g (global), m (multi-line), u (unicode), (to name a few).

In our example code, we use a /i at the very end of our regex which allows for a case-sensitive search.
ex.
(north)|(south)|(n|s))$/i

Character Escapes

When a character must be used which has a functional meaning within a regex, we can use a character escape. These are represented by a '\' or backslash. It is important to note that a '\' specifies a character escape, while a '/' or slash specifies the end of a regex.

In our example code, we use character escapes to specify both digits (\d) and white space (\s).
ex.
\d{2}
[mM'\.\-]\s?

Author

Elise LaBonte is a developer based in Weymouth, Massachusetts. She has been coding since 2020.

https://github.com/eliselabonte