Retired
Checkerboard Generation (retired)
413 of 1,062richardhsu
Loading description...
Algorithms
Loops
Control Flow
Basic Language Features
Fundamentals
Conditional Statements
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.
This kata is a subject to deduplication process here: https://github.com/codewars/content-issues/issues/82 Please join the discussion to share your opinions, and help us identify duplicate kata and retire them.
The use of loops and conditions is not tested, and the last sentence is complete nonsense. This should be removed.
Awesome kata, thanks!!!
Why do all the solutions voted as "Best Practice" have an O(n^2) runtime when there are easy to understand solutions with O(n) runtime?
Because O(n) runtime is impossible.
The output string is already O(n^2) so you can't do better than that.
But I have a O(1) solution :D
Codewars Forums - Kata Best Practices - Have Full Code Coverage
[JavaScript] While having 10 fixed assertions in the entire test suite is not that bad, it is still somewhat insufficient in preventing logically flawed and/or hardcoded solutions from passing. You should either (1) increase the total number of unique, distinct fixed assertions to at least 20 including edge cases or (2) write 100+ random tests as per standard Codewars practice and is generally preferred over just fixed tests.
So I have code that is doing a simular thing to other. Show the expected out and the instead got, appears to be the same. I believe it's because there's an extra new line at the end. However this only breaks when the size is an odd number. Works for checkerboard(8), but breaking on checkerboard(5). Not sure how to show anyone my code properly. Additionally, I've been researching how to remove the last occurance of a line break, but can't seem to find anything.
Used .trim() on my return statement, but that didn't work.
The description states that "You can [not MUST or MUST NOT] leave a newline character at the end of the full checkerboard", however, the tests are unambiguous - they specifically require that a trailing newline character is present in the "size > 1" case, and that a trailing newline character is NOT present in the "size < 1" case. This resulted in some confusion for me.
Thanks for the revision. Changed to MUST and clarified anything less than 1 should return an empty string without a newline ending.
What am I doing wrong here?
Output: Should return single square for size of 1 and should be a red square. Expected: [r] , instead got: [r] Should return alternating squares. Expected: [r][b] [b][r] , instead got: [r][b] [b][r]
Expected: [r][b][r] [b][r][b] [r][b][r] , instead got: [r][b][r] [b][r][b] [r][b][r]
Very likely it's the line ending that you have. I will add this note to all tests.
Got it, yeah, one extra at the end. Thanks.
The last test header says:
Should return single square for size of 1 and should be a red square.
Even though it's testing boards size > 1
This comment has been hidden.
Thanks for the suggestion. Although I do like the added difficulty of removing it from the end or making sure not to add or using
chomp
, I believe in a console application you'd want the\n
therefore I am leaving it.Then the "\n" should have also been appended to the empty string "". It's a bit inconsistent now.
The failure message is not clear enough when you forget the ending "\n".
( got something like :
...which is a bit confusing )
Hmm, well that would be an error on anything more than 1 line but I'll add that. Thanks!
Also, examples are wrong, they have no trailing \n. Fix them too.
Thanks. Got it.
Pretty cool kata. Nice and simple, but gets you thinking. Not sure why you pretty much hand all the optimization ideas on a platter in the description, though; part of the fun is coming up with your own strategies for that side of things.
As a personal preference, I tend to tweak the code so that it's just
function name() { }
instead ofname = function() { };
. Usually that works just fine, but with this kata it did not; why is that? Running the example test fixture worked fine with thefunction name() { }
form.Thanks for your feedback. It's difficult on the amount of details to give in descriptions as well as hints. I agree that part of the fun is coming up with your own strategies, but I also want to take this from a perspective of beginning programmers. Which ideas did you feel may have been too guiding?
As for the code tweak, I originally wrote
function name() { }
but when testing, I wasn't thinking and was testing forthis.name
in the full tests. I am re-publishing now for the change tofunction name() { }
. Thanks!I would just remove the whole
Possible Hints
section. Each point is either obvious, or too good a tip to give away. I think algorithms like this is a bit over the heads of beginning programmers. If they don't know how to make a loop, they won't be able to complete this kata, and if they do know how to make a loop, they'll know of at least one way of completing this kata already. I don't think problem solving is what new programmers need help with; it's the syntax and what's possible that they need to learn; which isn't what this kata is really about. Once they've solved it with a more naive solution, they can always look through other coder's solutions to learn other ways of doing things.Some more ideas:
In the description, you refer to the
new line sequence
. Normally it's called thenewline character
. Also, you don't actually say where to use a newline; you just tell us what it is. I was also a little confused as to why you want a newline character at the very end, when it's unnecessary, but that's more of a personal preference thing. If you don't want to change that part, just make this clearer, and that'd be good.You could also add something about what to do if the
size
isn't positive.Thanks for your feedback. I will remove the hints, I agree with you upon further thought. I think the examples and description provide enough to solve the challenge. Also I changed it to
newline character
as you suggested. I was torn by this because of the\r\n
for Windows machines. But since I'm using\n
, then it should be fine.I am leaving the newline at the end of the complete board because on terminal, it's better for visualization.
There are test cases for negative sizes and it is in the assumptions.
Thanks! Very helpful for my first kata creation :D
Cool. Heppy to help! ^^