Example tests are unreadable for solvers. They heavily use Preloaded code, which is not available to solvers, and we have to assume behaviour from names. This is not the intent of example tests.
Show the Preloaded code in the description, or at least explain what everything does, or move the code into Example tests ( and also into Submit tests, but that's your problem ), or - much preferred - write more readable code in Example tests. Code duplication is not a ( solver ) problem there; example tests are meant to be readable for solvers, and individual tests should preferably be visible in the window in their entirety, without having to scroll to find definitions of factored out code.
Example test #2 tests sfunctor.test. From the description, it is not clear that sfunctor.anythingButVal should exist, because it does not yet have state.
Either only expect sfunctor().anythingButVal to exist, or specify better that sfunctor.anythingButVal uncalled should return either sfunctor() or sfunctor ( and which one, and possibly why ).
The former option would make more sense IMO.
The same goes for sfunctor.val - the state is initialised on first call; what is the expected value here, and why? ( I don't know if this is actually tested. )
Alternatively, sfunctor could immediately have a default state, which might be overwritten normally on first call. But the initial code indicates this is not how things work.
Someone golfs
🤯
Shorter https://www.codewars.com/kata/reviews/5266876c8f4bf2da9b000365/groups/66bf3ade1baad7bd715acf82
this is js )
Insane JS techinical skill level, congratz
What in the name of god
what even is this?
approved at kyu 6
ad 2: but it is not clear from the description if
Function anonymousissfunctororsfunctor(), which have different behaviours.sfunctor.testto the example descriptionThis is a generally bad example of code, but I like the look of it)
Using undeclared variables is not a best practice.
fpollutes the global namespace ( and might be overwritten there ).Example tests are unreadable for solvers. They heavily use
Preloadedcode, which is not available to solvers, and we have to assume behaviour from names. This is not the intent of example tests.Show the
Preloadedcode in the description, or at least explain what everything does, or move the code intoExample tests( and also intoSubmit tests, but that's your problem ), or - much preferred - write more readable code inExample tests. Code duplication is not a ( solver ) problem there; example tests are meant to be readable for solvers, and individual tests should preferably be visible in the window in their entirety, without having to scroll to find definitions of factored out code.Example test #2 tests
sfunctor.test. From the description, it is not clear thatsfunctor.anythingButValshould exist, because it does not yet have state.Either only expect
sfunctor().anythingButValto exist, or specify better thatsfunctor.anythingButValuncalled should return eithersfunctor()orsfunctor( and which one, and possibly why ).The former option would make more sense IMO.
The same goes for
sfunctor.val- the state is initialised on first call; what is the expected value here, and why? ( I don't know if this is actually tested. )Alternatively,
sfunctorcould immediately have a default state, which might be overwritten normally on first call. But the initial code indicates this is not how things work.done
Loading more items...