Freecodecamp: Minor - Output neither captured nor used

[jeremylt]

Describe your problem and how to reproduce it:
For Basic JavaScript: Selecting from Many Options with Switch Statements, its a bit weird that caseInSwitch(1); is called but the output is not captured or used.

let result = caseInSwitch(1);

or

console.log(caseInSwitch(1)):

would be more typical.

See discussion here: https://www.freecodecamp.org/forum/t/basic-javascript-selecting-from-many-options-with-switch-statements-problem/404022/4

Add a Link to the page with the problem:
https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures/basic-javascript/selecting-from-many-options-with-switch-statements

Tell us about your browser and operating system:

• Browser Name: Firefox
• Browser Version: 77.0.1
• Operating System: Arch Linux

If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box):

[nhcarrigan]

A lot of the challenge seeds are set up with a function call at the end.
Factorialize a Number
Spinal Tap

I believe the idea is having a function call prepared allows the user to console.log() throughout their function to check that the steps of their algorithm are doing the correct thing.

[jeremylt]

Sure, but it's weird to call a function that does not have side effects and not capture the output. Do we want to demonstrate an antipattern?

[Sky020]

Just to expand on _nhcarrigan_: Campers are free as ever to wrap the pre-written function call in a console.log(). Personally, I am neither here nor there with this being a problem as:
1) Many challenges do not output anything to the console without the user taking initiative.
2) If we decide to add a console.log to the seed, then there are many challenges we would need to do this for...

[jeremylt]

Personally, I wouldn't add console.log() but I would capture the return value. The campers can decide what to do to sanity check the output.

That said, it's totally fair if we don't want to do it because we'll have v7 coming at some point in the future. But it is odd to call a function with no side effects and not capture the return value.

[Sky020]

capture the return value.

Sorry, I am not understanding what you mean by this? What is an example of _"captur[ing]"_ the value?
The tests do use it, if that is what you mean...as in, the return is vital for the challenge.

[jeremylt]

I mean doing this:

let result = caseInSwitch(1);

The tests do use the return value, yeah. It's just weird to me that we show examples in the Do Not Change part of the code of ignoring a return value on a function. The function executes and the result is discarded.

[Sky020]

Ok, now I understand. On the one hand, seeing as many of these challenges are merely focused on the syntax, having the user write something that does absolutely nothing is still useful. On the other hand, exactly as you mentioned, v7 does this combined with _functional_ functional programming.

So, shall we add some functionality to the seed? Or, leave it as is?

[ojeytonwilliams]

To give a bit of context, I think the tests used to rely on the return value from an eval of the user's code. Hence the weird function calls that seem to do nothing.

That's no longer the case, so ideally these would be captured, logged or removed. If anyone wants to do this, that's fine, but I wouldn't consider it a high priority - since it's just weird, rather than broken.

[lasjorg]

I think it's a good idea to have the function call. It shows how the function is called and what arguments are passed to the function without having to look at the test cases.

But I agree it would be better to use the return value.

Wrapping function calls in console logs can confuse some new learners just a bit I think. Capturing the return and logging it is more verbose but also more explicit about the function having a return value and it allows for the use of a variable name that may help "document" the code.

const returnAnswer = caseInSwitch(1);
console.log(returnAnswer);

[thecodingaviator]

If we're doing this for one challenge, we might as well do it for every challenge. Doing it just for one just doesn't make sense. In addition, referring to https://github.com/freeCodeCamp/freeCodeCamp/issues/39082#issuecomment-645326278 , I agree that this is weird and low-priority. Doing it for every challenge would take up a lot of work though, as such, I'd consider it bikeshedding, but what do you guys think @freeCodeCamp/moderators ?

[jeremylt]

I agree that this is weird and low priority. I only brought it up because I was helping someone on the forum who got a bit confused by it.

On the forum we, or at least I, try to talk about to best practices or reasons for writing code a specific way. Thats not congruent with modeling code that wouldn't be used.

Pedagogicaly, I'd say it might be worth updating this any time we make other changes to a challenge instead of sending the time to make a big pass to catch all the them.

I don't have time to mod on the forums and contribute here, so I don't have a big vote here, IMHO. I'm fine with changing or not, as best fits the development plan over here. I only wanted to bring it up for discussion/intentional decision.

[RandellDawson]

Quite a while back we purposely removed most (I thought all) console.log statements that appeared after a function. The idea was if the user wanted use a console.log statement, then that was their choice. They do learn about them at some point in the curriculum. I believe we should not have console.log statements by default on these challenges until we have introduced them (Debugging section).

[jeremylt]

Agreed. I'd just capture the output in a variable, personally.

[moT01]

I'm going to vote against changing these. It doesn't seem worth the effort at the moment.

If we're doing this for one challenge, we might as well do it for every challenge.

It doesn't sound too bad, but it feels like very little gain for a lot of work in my opinion. I would rather keep them somewhat consistent then change them one at a time as PR's for challenges come in.