Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
Hey, check it out.
Dart translate
I propose add test cases with 3 spaces, and 4, 5 spaces between words. Almost all solutions do not save 3 spaces between words.
The test cases are wrong. It shows an expected output with numbers that aren't in the original matrix, besides i had to click on the attempt button several times without changing the code until it finally marked my solution as correct.
Whats happening? What did i do wrong?
Expected: "elbuod decaps sdrow", instead got: "elbuod decaps sdrow"
Expected: "ehT kciuq nworb xof spmuj revo eht yzal .god", instead got: "ehT kciuq nworb xof spmuj revo eht yzal .god"
expected:<[ ]> but was:<[]> i am unable to get this test case help!
Languages are inconsistent w.r.t. handling of adjacent, leading, and trailing spaces. Some languages test for those, some do not, and some generate such inputs by pure accident.
Languages should be unified and either all of them should have corresponding tests (also random), or such inputs should not be generated. If tests would contain extensive test cases for spaces, they most probably should take care to include inputs with double (or more) leading spaces, and double (or more) trailing spaces.
Language: C++
Test suit missing the required header
std::string
Lua translation!
D translation
NO random tests
Missing fixed tests for
Y
,Draw
&&In progress
This one should be reranked or sent back to beta (so don't resolve this until it's done)
No random tests in CS & JS
No sample tests in CS & JS
Test.expect
should be replacedJS Node 18. (
mocha + chai
) should be enabledThis comment is hidden because it contains spoiler information about the solution
The tests don't check for multi-char glyphs. This means that naive implementations (most, if not all submitted, including mine) would corrupt the strings with multi-char glyphs in them by reversing order of chars in them. Either add test cases for those or add the assumption that input strings are ASCII in instructions.
This comment is hidden because it contains spoiler information about the solution
No random tests.
Loading more items...