JavaScript Mastery

Can You Spot The Bug?

Do you trust your JavaScript skills? Then come and try whether you can find the bugs in these snippets.

JavaScript is a kind of programming language that is pretty easy to pick up but extremely hard to master. That’s because of the inconsistencies across the language. For instance, something that works in a normal function can cause a bug in arrow functions. Since the web is, as its name states, a node web that contains tens of thousands of interconnected nodes, changing a feature that is implemented 10 years ago in the core of the web, which is JavaScript, would cause millions of websites to crash. Consequently, this backward compatibility issue let the inconsistencies survive for many years.

In this story, I will show you 3 JavaScript code snippets that hide a bunch of bugs inside, very well. Try yourself and find them without looking at the explanation right below the snippet. Let’s see whether you are a real JavaScript ninja.

1. Indeed, I Initialized It

Here’s the first buggy code snippet and I think if you have a long-term relationship with JavaScript, you’ll notice the issue immediately.

What I am trying to do is to log not and buggy variables one by one. Since I am too lazy to write one more line, I put them in an array and use forEach to log them out.

However, when I run this code interpreter shouts that I tried to access the buggy variable before initialization. But I apparently didn't.

What’s wrong with this code?

Explanation

The first thing every newbie learns in JavaScript is that semicolons (;) are optional. You can use them if you want but it is not a problem if you prefer not to.

Well, I am the one who prefers not to use them because they make the code look cluttered. For 99% of the time, not using semicolons is not a problem, at all. However, this snippet is in the 1%. By looking at the code, we see no issue because we separate each statement line by line. This is not the case for the interpreter.

You know that you can access individual characters of a string using brackets ([]) and an index number, as you do in arrays. In the buggy code snippet above, if you scan one more time, you’ll see that after the string buggy, I used brackets to create an array of variables, at least that was what I intended. But the interpreter thought that I tried to access the characters of the string.

So, here’s the same code from the interpreter's point of view.

Since I try to use buggy in the declaration of buggy, the interpreter says I cannot access it.

So, how to fix it? It is pretty easy, you can use semicolons at the end of every line and get rid of these kinds of issues once and for all. Or you simply put a semicolon right before the array and separate it manually from the previous string.

2. Let Me Out, I’m In An Infinite Loop

In one of my projects, I was dealing with the atoms’ weight and you know that they are so small and light. Something like 2 to the power of -324 kg (I know that is not the real weight). And at some point, I had to add the mass of an atom to 5 and create a while loop around it.

I pass a value to massOfAnAtom using scientific notation, which is basically an easier way to write powers of 10. In the loop body, I add the mass of the atom to the main mass. I expected the while loop to run only once because in the first iteration, we add another number to 5 and the condition isn’t satisfied anymore; mainMass is bigger than 5, now.

However, instead, I get an infinite loop that logs 5 over and over.

What’s wrong with this code?

Explanation

The arithmetic of computers is quite different from our world. We have 10 figures (0–9) to represent any number but in the machine world, there are only 0 and 1. So, everything we write in the code should be converted to 0s and 1s.

Besides, unlike us, computers have limited memory for each variable. For instance, computers can allocate 4 bytes of memory for a Number. That’s why there’s a max and min value that can be parsed by the interpreter. You can access these values with Number.MAX_VALUE and Number.MIN_VALUE.

In the code above, 2e-324 is such a small number that it cannot be expressed as 0s and 1s using allocated memory, which is called underflow. So, JavaScript simply converts it to 0, and in the while loop, it simply adds 0s to 5. Consequently, this causes an infinite loop.

You would think that it is a bad thing that JavaScript converts a meaningful number to 0. However, it is not; that only shows that JavaScript is a safe language because if the number causes underflow or overflow, this would lead to horrible scenarios.

3. All I Want Is An Object In Return

Here’s the last snippet of this article and I think this is the most common one among others.

I created a function named createPerson and all it should do is to give me an object created using the parameters I passed to the function.

In the arrow functions, when a value is directly written right after the arrow, that means it is returned implicitly. In the code above, I did the exact same thing. I wrote the object I want to return, immediately. So, I should see the object created in the log.

However, the terminal shouts to me to correct my code and come again.

What’s wrong with this code?

Explanation

Let’s assume you don’t return an object from that function but rather do some other funky stuff with it. How would the syntax change?

As you see, we again used the curly braces in the same spot as the previous one. And now, there’s no error with the code above. Because curly braces, apart from creating objects, define code blocks and the bodies of the function. So, when you put curly braces right after the arrow, it is interpreted as the body of the arrow function, not an object you want to return. Consequently, putting colons and commas, JavaScript threw an error.

To return an object from an arrow function, you can either use regular explicit return or implicit return with parentheses so that curly braces are interpreted correctly.

Now, the code is fixed and works as intended.

Conclusion

For us, developers, dealing with the bugs is much more time-consuming than writing the buggy code. Sometimes we have to constantly stare at the same code snippet for hours and keep 34 Chrome tabs open. However, learning the weak points that could cause bugs saves us invaluable time so that we can deal with other bugs.

In the response section, write how many bugs you spotted without looking at the explanation.

Hope you liked this story. If so, make sure you clapped. This means the world to me. See you in the next story.

Enjoy reading stories like these and want to support me as a writer? Consider signing up to become a Medium member. It’s $5 a month, giving you unlimited access to stories on Medium. If you sign up using my link, I’ll earn a small commission.

Related