The short version is: your function should return a zero and also have a zero score/size
The long version comes with a little history:
There is a long tradition of attempting to modify the scoring function in Cody to be able to create problems that score solutions, for example, based on the solution running-time instead of the solution code-complexity. There is, of course, a parallel tradition of Cody players trying to "game" the system into getting the lowest possible score for their solutions.
Cody players are a very resourceful crowd, and very early into the game they found that overwriting the solution file (after it was evaluated) did the trick: Cody would then evaluate your solution size/code-complexity from the contents of the overwritten file so problem creators could overwrite the solutions with specially-crafted files that would return the desired solution score. Also solvers could overwrite their own files to get a 0 score if they so wished, simply adding
!echo "%" > my_fcn_name.m
to their solutions.
That state of affairs, naturally, perhaps sadly, did not last long, and Cody machinery was modified to score the solutions before the testsuite was run.
Of course this fix lasted even shorter, and Cody players found that the variable where that score was being stored could be accessed from the testsuite code using evalin('caller',...) or assignin('caller',...) syntax (yes, that variable was very amicably named score). So cody creators could now add the line
to their testsuite to give players a 0 (or any arbitrary) score.
This new scenario lasted for quite some time, probably because while problem creators could still modify the scoring function as they wish and create all forms of problems that departed from the size/complexity-based scoring, problem solvers could not do the same to get any arbitrary score. From the solution function perspective the variable score was two(!) steps up in the stack, and there is simply no way to use evalin('caller',...) syntax recursively along the lines of
Somewhat recently this situation changed again and Cody started using the Unit Testing framework to run solutions. That put a lot of layers between the testsuite and the coveted workspace where the score variable lived, making the assignin trick obsolete. In addition key Cody functionality was hidden into .p files, which added a small burden to exploring the inner workings of Cody, and the old score variable was nowhere to be found in those new functions.
Your job in this problem, following this proud tradition, is to get a zero score. Also your solution function should return a 0 as well, just to make it do something.
A few pointers to get you started would be:
Good luck and please hack responsibly!
ps1. if you are thinking of submitting an empty solution, no, that does not count (that is not a function and that is not returning any number).
ps2. if you are thinking of copy/pasting my own SetSolutionScore trick, that will not work here, sorry! (it is protected so that it only works when the testsuite code uses it; if you manage to disable this protection and make it work from within your solution file I will accept that as well as a valid solution)
ps3. if you want to use SetSolutionScore to be able to assign not-size-based scores in your own problems, simply copy/paste the relevant code in this problem testsuite. SetSolutionScore, like the old assignin trick, will not interfere with other problems (solvers cannot copy/paste your testsuite code to get zero-scores in other problems)
note: please refrain from using this sort of Cody tricks to get leading scores in general non-hacking problems. That is just discorteous to other players (add here rant about the regexp trick and how leading scores used to be worth pursuing).