Cody challenge hard coded answers

3 Ansichten (letzte 30 Tage)
Shlomo Geva
Shlomo Geva am 14 Nov. 2020
Kommentiert: Walter Roberson am 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

Antworten (1)

John D'Errico
John D'Errico am 15 Nov. 2020
Bearbeitet: John D'Errico am 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 Kommentare
John D'Errico
John D'Errico am 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 am 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.)

Melden Sie sich an, um zu kommentieren.

Kategorien

Mehr zu Search Path finden Sie in Help Center und File Exchange

Tags

Community Treasure Hunt

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

Start Hunting!

Translated by