How are answers evaluated?

I’m curious if the evaluation function – the FCC (freeCodeCamp) logic/code that checks if an answer is correct or not – looks for certain keywords, or if it just scoops up the relevant code and eval()s it?

I ask because I answered the following question in a way that seemed to produce a correct result – according to a pen – but it was still marked as incorrect by FCC.

when i changed my code to do what I thought FCC wanted me to do - in terms of a solution - then it worked – that is, the answer was marked ‘correct’.


Please provide your code so we can see what’s going on. Thanks!

This is the entire code – original plus my changes.

The test that was failing was because the song, “Take a Chance on Me”, was supposed to be the last in the 5439 object’s ‘tracks’ array:

// Setup
var collection = {
  2548: {
    albumTitle: 'Slippery When Wet',
    artist: 'Bon Jovi',
    tracks: ['Let It Rock', 'You Give Love a Bad Name']
  2468: {
    albumTitle: '1999',
    artist: 'Prince',
    tracks: ['1999', 'Little Red Corvette']
  1245: {
    artist: 'Robert Palmer',
    tracks: []
  5439: {
    albumTitle: 'ABBA Gold'

// Only change code below this line
function updateRecords(object, id, prop, value) {
  if(prop!='tracks' && value!==''){
  else if(prop==='tracks' && !('tracks' in object[id])){
    newTrackArray = [value];
    object[id]['tracks'] = newTrackArray;
  else if(prop==='tracks' && value!==''){
  else {
    if (value===''){
      delete object[id][prop];
  return object;

updateRecords(collection, 5439, "tracks", "Take a Chance on Me");


You aren’t checking for value !== '' here. (though you can avoid that repetitive check by putting the case where value === '' first)

1 Like

try to call the failed test in the editor
it will tell that newTrackArray is mot defined

darn, that could def be it – i confirm i see the error.

i tried to copy/paste the solution directly to codepen, and tried to share the direct codepen link, but had trouble.

so this is a bit trippy.

tldr; i think my original answer should have been marked correct, and the reason i didn’t see the ReferenceError wrt the newTrackArray error is because it is not actually an error - it’s a global variable - and the error did not show up for me originally because I had also modified the line(s) at the bottom of the editor (which is prob not generally advisable), thus seemingly/potentially confusing the evaluation function.

i was/am pretty sure i didn’t see that error before – until i just checked again by copy/pasting my own code from here back into the editor, like @ilenia suggested.

so in going back to try to figure out why i might not have seen it before, i was able to replicate (probably?) what was happening before.

first, i think my solution was generally ‘correct’ in that it should have satisfied the requirements of the exercise. that is, if you inspected the object at the end, it would have been exactly what it should have been.

(tldr; i think it is javascript-legal to declare/use variables without explicitly declaring them with a ‘var’ or ‘let’ keyword – they just become global vars, which is prob not generally a good thing, even if they’re syntactically valid.)

second, i think it’s good that the evaluation mechanism at least highlights, in background-red, potential variable problems (as it does sometimes in my testing), and in other times actually explicitly points out and logs a ‘ReferenceError’ - as pointed out by @ilenia.

and the key to my changing results are the updateRecords() and console.log() statements i added/changed at the bottom of the editor (my bad!).

so, what i saw initially is shown in the screenshot below:

  • newTrackArray is not declared with var
  • i commented out my later-added javascript function calls to updateRecords() and console.log() – seen in green.
  • only one test fails
  • there is no ReferenceError shown (due to newTrackArray)
  • newTrackArray is not highlighted in red in this specific scenario, but it is in others – depending on whether I have modified/added/removed any other functions to the bottom of the editor (this is a cool feature)

so that kind of gets to why i originally asked how answers are evaluated.

i do think there is something small here to improve, if it’s possible to articulate it.

  1. i think my original solution should be evaluated to ‘correct’ – all tests should pass
  2. we can maybe be explicit about requiring the use of only local variables
  3. maybe we can avert any ‘weirdness’ like i introduced by just adding a simple //do not change anything below this line as appears in other exercises

just some ideas.

IMPORTANT: Your diagnosis has some serious misconceptions that will cause problems for you down the road if you don’t repair them.

This isn’t a question of ‘only using local variables’. The issues has nothing to do with variable scope. You should declare any variable you use. A comment wouldn’t fix an undeclared variable added by the user.

Unfortunately, strict mode enforcement of variable declaration is not uniformly enforced, which is why you did not see this issue in codepen. To enable strict mode enforcement in codepen, add "use strict"; as the first line of your code.

The fact that undeclared variables are automagically declared in the global scope when strict mode is not enforced is not why your code failed. You code failed because freeCodeCamp’s editor enforces strict mode and codepin does not.

And you still are missing a piece of the logic. If you declare newTrackArray, you fix this problem you’re seeing about an undeclared variable, but you still will end up with a problem that you can see by running

updateRecords(collection, 5439, "tracks", "");

The output is wrong in this case.

so, if the code pasted above is only changed by declaring newTrackArray with a var, and the output is wrong for the test case you specify, then the test would fail, if the test was correct/accurate, right?

but the test passes.

so, taking the code from above, and change this:

newTrackArray = [value];

to this:

var newTrackArray = [value];

and the code passes.

but i think you are saying it should not pass, right?

I think there is a gap in the test cases. In the input I showed, the tracks should be deleted, but there is still an array.

I think it expects only valid input, so there is no case in which the tests try to delete something that is not there

(5439 does not have a tracks array)

But why isn’t it a valid input? Double deletion is something that actually occurs in practical applications and it should result in accurate output.

That behavior would be consistent with the behavior of the delete function

If the property which you are trying to delete does not exist, delete will not have any effect and will return true .

Deleting properties that aren’t present is a perfectly legal operation that conventionally results in a no-op.

so, to try to sum up something from all this…

  1. the evaluation function is wrong or incomplete
  2. the first listed solution, Solution 1, is wrong (from Hints section)

the second solution, ‘Solution 2’, works, tho.

the strict/variable stuff seems like a big topic.

but i figured out why the ReferenceError only shows up sometimes – when I put my own updateRecords() function call at the bottom of the editor, it forced the virtual/Editor/strict-checker stream of execution (presumably?) to go through the non-strict-code – which then triggered the ReferenceError.

so, not sure if that is possible – have the ‘strict check’ just check every possible path through the code – like 100% test coverage.

Original bottom of code:

updateRecords(collection, 5439, 'artist', 'ABBA');

Bottom of code in my sample code:

updateRecords(collection, 5439, "tracks", "Take a Chance on Me");

it translate exactly the bullet points, and as in the tests there is no deletion of a property that doesn’t exist, it works - if the tests would change, then it would be a different thing

if you run the tests with the browser console open it appear every time

strict mode makes so that some errors that would fail silenty or work anyway would instead stop execution, including undeclared variables

the tests usually call the function with an input and check if the output matches, 100% coverage is impossible, you can’t add every possible input

I think this challenge was made to be as simple as possible and that includes being able to translate the requirements literally, it’s one of the first great obstacles, increasing complexity would make it even more difficult - if it was in the Algorithms section I would totally agree tho

I really don’t agree the we decided it’s ‘good’ to be coy with the fact that you can simplify the requirements by working the list top to bottom. That would avoid that issue, simplify the challenge, and produce consistent behavior with double use of delete.

then maybe it’s time to rework the challenge description, and add some other tests

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