Declaring variable multiple times

Tell us what’s happening:

Why would the solution to this challenge declare a variable multiple times in the same script? Regardless of the scope this is absolutely terrible practice. This solutions should be offering best practices.

Your code so far

    const squareList = (arr) => {
      "use strict";
      const squaredIntegers = arr.filter( (num) => num > 0 && num % parseInt(num) === 0 ).map( (num) => Math.pow(num, 2) );
      return squaredIntegers;

    // test your code
    const squaredIntegers = squareList(realNumberArray);

Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36.

Link to the challenge:

The two declarations of squaredIntegers are not the same variable. Rather, they are two variables with the same name.As you may recall from the scoping lessons, variables which are declared inside a function (using var, let, or const) exist only within that function.

He’s sort of right, that function is better off being a return ... one liner. If you insist on declaring a variable there then you are probably better off using a more descriptive function name and just calling the variable result or smth like that.

Has nothing to do with scope, just being consistent and descriptive with your naming conventions.

1 Like

That’s why I specified “regardless of scope”. freecodecamp has a bad habit of taking challenges far outside the scope of the examples given. Throwing in identical variable names in different scopes adds to confusion. I think this challenge could definitely be re-written to more clearly illustrate the objective.

const realNumberArray = [4, 5.6, -9.8, 3.14, 42, 6, 8.34, -2];
const squareList = (arr) => arr.filter( (num) => num > 0 && num % parseInt(num) === 0 ).map( (num) => Math.pow(num, 2) );
// test your code

The suggested solutions are all written and submitted by campers. You can very easily submit a PR to improve the guide article. Here is the relevant portion of the Contributing Guide.

1 Like

Almost all of the challenges which have the IIFEs have been recently updated to remove them. Once the changes have been deployed to production, it will be less confusing.

Is the usage of “use script”; a byproduct of the testing platform? Because it’s been a very long time since I’ve seen anyone use that declaration in production code.

I understand , and I know that you have told me multiple times that they are updated in the github repository. I’m not proficient enough with github to navigate and find the updated code. I don’t think it should be expected of someone to check the repository to see if the code is different than what is provided in the solution. If that is the expectation could someone provide a short tutorial? I would love to be able to jump into the repository and contribute, but to be honest it’s a little daunting.

“use strict” is best practice when developing code. It’s probably not used in production, would be my guess.

Actually now looking at the repository it appears this challenge has been replaced. I don’t see it in the repository.

Thanks, maybe I’ll give it a try. I’ve really been wanting to start working on an OSP but it’s intimidating.

It was moved to the Functional Programming section (PR).

1 Like

You are not expected to view the updated challenge on GitHub. I was just merely pointing out that in the near future, these challenges will be a little more clear to beginners and not have all the extra non-explained parts. Most of the IIFEs were put in place prior to some other changes in the repo related to how the tests work. We were able to remove them after changes were made to how the test runner executes.

1 Like