FAQ: Code Challenges: Intermediate JavaScript - squareNums()


This community-built FAQ covers the “squareNums()” exercise from the lesson “Code Challenges: Intermediate JavaScript”.

Paths and Courses
This exercise can be found in the following Codecademy content:

Web Development

FAQs on the exercise squareNums()

Join the Discussion. Help a fellow learner on their journey.

Ask or answer a question about this exercise by clicking reply (reply) below!

Agree with a comment or answer? Like (like) to up-vote the contribution!

Need broader help or resources? Head here.

Looking for motivation to keep learning? Join our wider discussions.

Learn more about how to use this guide.

Found a bug? Report it!

Have a question about your account or billing? Reach out to our customer support team!

None of the above? Find out where to ask other questions here!


Newbie here… getting frustrated with what appears to be correct code but fails to be recognized as correct. Which means that if I don’t do it exactly as the system has it, I can’t move on… talk about taking the wind out of your sales as a new programmer.

In this exercise I used the following as my function:

const squareNums = (array) =>{

I eventually gave in and asked for the solution which looks similar (spoiler alert) albeit all on one line.

I understand that passing one array does not require the parentheses while they are required when passing zero or multiples, however, in previous exercises when I didn’t include them, my code failed. Based on that, I’ve been including them.

The error message at the bottom of the code window kept popping up with “did you pass a function into a map() that takes a number and returns is square?” I thought I had, but it wouldn’t pass me on to the next exercise.

Is my code syntax correct, even if it doesn’t match the book? Suggestions on how I should be approaching future exercises on Codecademy?


In this particular example, your syntax is a bit off :slight_smile:

With arrow functions, if you include curly brackets after the arrow, you need to explicitly write return to return anything from the function. If the only statement in your function is a return statement, then you can remove both the return and brackets.

Because your function has curly brackets but no return before array.map(toSquare), it effectively throws away the result of map, and just returns undefined.

So you can either remove the brackets or add a return to get the function working.


Nothing is returned, literally. JS interprets this as undefined, not the actual return value.


Hmm, I thought undefined would be the actual return value based on Mozilla’s article about functions:

A function without a return statement will return a default value. In the case of a constructor called with the new keyword, the default value is the value of its this parameter. For all other functions, the default return value is undefined.

Or are we saying the same thing? Just curious as I’m pretty new to Javascript.

 > function foo() {

<- undefined
 > foo() && 'a'
<- undefined

It appears my understanding may be lacking. In Python the above would echo nothing to the console. My only question still remains, where is undefined injected into the data stream? At the function? Or at the caller?


where is undefined injected into the data stream? At the function? Or at the caller?

I suppose the function since it is the return value. I tried debugging this in VS Code:

function doThings() { 
  const x = 'abc';


When the debugger reaches the closing bracket of doThings, “return value: undefined” is displayed in the Variables window.

Interestingly, it seems Python is actually similar...

…but its default return value is None. I found this in the Python 3 documentation:

In fact, even functions without a return statement do return a value, albeit a rather boring one. This value is called None (it’s a built-in name). Writing the value None is normally suppressed by the interpreter if it would be the only value written. You can see it if you really want to using print()

The return statement returns with a value from a function. return without an expression argument returns None . Falling off the end of a function also returns None .

When I run this, I do see “None” in the console:

def doNothing(): pass


So in other words, a value is returned? That would mean an implicit return in all cases. Then why require a return keyword at all? Ruby seems to have figured this out, but JS is only fudging it, as far as I can make out.


I don’t know if it’s considered an implicit return, since it just returns undefined and not the value of the last expression in the function.

In Ruby, this prints “hello world”, like you’re indicating:

def doStuff()
   'hello world'
puts doStuff()

Whereas in JavaScript, this just prints “undefined”:

function doStuff() { 
  'hello world';

I think in Javascript, the only functions with implicit return values are arrow functions with no curly brackets. From Mozilla’s arrow functions documentation:

Arrow functions can have either a “concise body” or the usual “block body”.

In a concise body, only an expression is specified, which becomes the implicit return value. In a block body, you must use an explicit return statement.

So this function with no curly brackets does print “hello world”:

const doStuff = () => 'hello world';

But this, with brackets, prints undefined again:

const doStuff = () => { 'hello world' };


Python treats nothing like nothing. There is no indication in the response that anything was returned. Only if we print it will it appear as None. As an object it doesn’t even qualify a newline. All we get is a command prompt in response. There is no indication there was a response to echo.

Mathematicians racked their brains around the idea of nothingness, and a little background research will reveal what a slam dunk it was once zero came into the picture.

The founders of Calculus are not Leibniz or Newton, but a host of others along a path from which they inherited. Both had amazing insight into nature, though I venture Newton excelled here, and both had amazing insight into maths. Neither can be seen to exceed the other, though historically one is held the victor.

There was never anything amiss about the RPN of the Hewlett Packard calculators of the seventies.


Some stuff doesn’t survive economic forces, but it still deserves to survive historically. Particularly when we consider how we program.

a = 6
b = 7

We load the registers first.

return a OP b

We apply the operator second.

Typical programming stuff that just never took hold in hand held calculators. Pity.

Mind, today we don’t need calculators…