Const FCC declared but not recognised by UI

Tell us what’s happening:

I am declaring a read-only variable FCC using const.
My cases are correct.
I am still receiving an error from the UI even though I am obeying the rules.

const FCC = “FreeCodeCamp”; // Change this line

let fact = “is cool!”; // Change this line

fact = “is awesome!”;

console.log(FCC, fact); // Change this line

Your code so far

const FCC = "FreeCodeCamp"; // Change this line
let fact = "is cool!"; // Change this line
fact = "is awesome!";
console.log(FCC, fact); // Change this line

Your browser information:

User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.61 Safari/537.36

Challenge: Declare a Read-Only Variable with the const Keyword

Link to the challenge:

OMG it’s because I changed freeCodeCamp to FreeCodeCamp which has nothing to do with the code but still throws up an error, which is incorrectly described by the UI.
Bug.

It is not a bug. Changing parts of the code that you were not told to change can break code. You should only make the requested changes in these challenges. Doing otherwise means that you have written a bug.

The UI incorrectly described the problem = bug.

You changed things that you should not = bug

So you’re saying that the Help statements don’t have to be accurate? How are they helpful then?

I’m saying that you wrote a bug in your code. I’m digging into the test to see how we test this, but I’m not sure if there is as clear way to catch this user bug.

As a learner, I would expect to make mistakes… but I would not expect your UI, created by experts, to contain errors. It wouldn’t matter so much except that the user is prevented from progressing. I’m having a similar issue with the next challenge in fact… where the Help statement is giving me an instruction which I’ve already fulfilled, but I am not allowed to progress.

It is literally impossible for us to come up with every possible bug you could write. We might be able to make an easy tweak to the tests to catch this one, but in general you can’t expect every challenge to catch every possible way for users to make mistakes.

That’s what’s coming to mind for me. We could also split the relevant test into two parts, but it’s already a high number of tests for a simple task.

The Help message said: FCC should be a constant variable declared with const
I was already doing that.
But because I changed freeCodeCamp to FreeCodeCamp (because I took the capitalisation rule too literally) the code wouldn’t pass.

I started an issue with two suggestions since occasionally we have a user that misreads the instructions on this challenge. An update to the instructions and a new test are my two suggestions for possible clarifications. It still feels like a lot of tests for 4 small edits, but I don’t see a different way to be super specific about this particular misunderstanding.

I suppose my point is that I’m on the fence about if we want to check if those values weren’t changed. Blindly capitalizing would be a sign of misunderstanding, so I suppose that we do need these checks.

In my mind, it’s less a question of if specific guidance is helpful but rather which things are worth checking for.

Hi Randell, thanks for listening. This challenge is near the beginning of the sequence and could easily put people off from continuing, which is why I’d say it’s worth trying to make it crystal clear.
Maybe, rather than waiting for written feedback from novice users, you could monitor how many people give up at this point to determine how worthwhile it might be to make changes?
Thanks again, Ursula.

We can see where users stop, but we can only make guesses as to why without actual information.

Well now you’re aware of the problem in this case, I think it would be reasonable to assume that atleast some people may stop at this point because they are unable to find a way to progress?

You could do a quick comparison of how many users stop at this point, compared with how many users stop at other points in the sequence of challenges, and draw conclusions.

We could draw uninformed conclusions, sure. There is no good substitute for seeing what questions get asked.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.