6 kyu
Fill None
184 of 306Fbasham
Loading description...
Fundamentals
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
I think the instruction is missing a rule for method beging 0 and the distance to the nearest number is equal in both directions. It seems to be, that in that case, the smaller of both numbers should be chosen.
the kata description already mentions this detail
Haskell translation
this translation modifies the description
Approved. Thank you!
Pretty funny and quite simple kata to exercise with, well done.
javascript translation with attempt at making the description a bit more language agnostic
Thanks!
fork to close below issue.
.
Great kata! I wonder why it has been stuck in beta for so long now!
solution
andcodewars_test
are missing.None
. Is it necessary to skip strings when searching for a nearest int?done.
Test cases would have a better shape and would be more readable and maintainable if they were factorized. I suggest to create a function
dotest
that handles all test cases. Then all the fixed tests could be grouped in a list[(input, expected)]
, without repeatingtest.assert_equals
x times.In my, highly personal, opinion, readability is actually better served by repeating
test.assert_equals
, and maintainability of simple code is better, even if you would have to patch the tests umpteen times to change something - but it's probably always the same change.I prefer not having to read complicated code in some other place to fully interpret tests. And I have no limitless trust in authors not to introduce bugs in that code.
This might be worth discussing on Discord.
In fixed tests
fill
should receive a copy of the "array".The same list is used three times, if the function changes the list, second and third call will receive a modified list.
True. Fixed.
Hi,
missing fixed test:
0 [4, 5, None, None, None, 2, None, 2]
Just added.
.
.
Good catch. Reworded such that it should pick the smallest int for equidistant pairs.