Cody challenge hard coded answers

3 views (last 30 days)
Shlomo Geva
Shlomo Geva on 14 Nov 2020
Commented: Walter Roberson on 16 Nov 2020
I have been using something similar to the Cody Challenge problem solving rig for many years (albeit more sophisticated) in teaching various programming languages, including Matlab. While browsing through some Cody problems and solutions, I noticed that some solutions consist of just hard coded responsese to the test input.
For instance, a solution to problem 63 (decimal to roman conversion) encodes the test cases, and appears as a valid solution.
Cody is just for fun and someone probably decided to play silly buggers, but still, should this appear as a correct solution when it is not?
function romStr = dec2rom(n)
d = [1990, 2008, 1666, 49, 45, 0];
r = {'MCMXC', 'MMVIII', 'MDCLXVI', 'XLIX', 'XLV', ''};
romStr = r{d==n};
end

Answers (1)

John D'Errico
John D'Errico on 15 Nov 2020
Edited: John D'Errico on 15 Nov 2020
Should it?
Not really, but what are you going to do? A good problem should include at least one random test input. But that also implies the problem author knows how to solve the problem themselves, not always the case. Are all of the Cody problems well written, with good test cases? No. Such is life.
Is it really worth worrying about?
  5 Comments
John D'Errico
John D'Errico on 16 Nov 2020
I said that myself, is that ALL Cody probblems should have a random test as one of the tests. Should any half decent programmer know how to do that? Well, yes. But the fact remains, Cody does not restrict anyone from submitting a problem. And that results in many problems with a terribly easy set of tests to game. Cody is what it is.
Walter Roberson
Walter Roberson on 16 Nov 2020
There are a lot of programmers who are terrible at writing tests. Programmers are quite prone to only thinking about something one way, and not realizing that other inputs are even possible let alone will cause a problem.
This is the reason that writing good test cases is an art: it takes skills to think of good ways to break a program.
But programmers tend to think that they have those skills, so it is common for programmers to look down on testers and refuse to cooperate with them. And then when the product ships with significant bugs because the testers could not get cooperation, it is the testers who get blamed. :(
(I know some professional testers.)

Sign in to comment.

Categories

Find more on Search Path in Help Center and File Exchange

Tags

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!