Thanks for the heads-up! You’re right that under this kata’s rules (ASCII letters only, case-insensitive, empty → false), “xgx” is a palindrome.

I’ve:

• Clarified the description to state that single-letter results do count as palindromes.
• Updated the tests: the case for "xgx" now expects true, added a contrasting "xgy" => false, and expanded samples/hidden tests accordingly.

Please give it another try with the updated tests. If anything still looks off, ping me and I’ll adjust fast.

thank you for your response! i will work a little bit more on that kata :) i hope you enjoyed it anyway

Should NOT be palindrome: xgx
Failed asserting that true is false.

xgx is a palindrome

approved

hey, no hard feelings, I also wrote awkward stuff in my own old translations

• having a constant named by its value is really weird. that means that if you change its value, you also have to change its name... FOUR should rather be N, or COUNT, or LENGTH, something like that. Same thing for ONE, but you can remove it altogether since it's only used for ab_min.
• I made a mistake in my last message: rand() % a + b gives you a range of [b, a + b[, not [a, b[, sorry for the confusion. The use of ranges and the signature of rand_int() make the logic hard to follow. Seeing a function rand_int(a, b) most people will assume it returns an integer in [a, b] (possibly exclusive of b). I think the original intent was that mn_ranges and ab_ranges are actually mn_max and ab_max, respectively ? It would be clearer to have a rand_int(min, max) function, and pick those min/max values from the arrays.

short answer: i wrote this seven years ago

for the record, what you saw here included a ton of alterations & improvements i did maybe about a month ago; it reflects my modern syntax

hope my fixes today make it more clear

I've been thinking about it too

• can you return something in the initial code ?
• It took me a while to understand how the random tests were working:
  • Please move variable declarations to the point where they are actually used. Declaring everything at the top is an old style that dates back to the pre-C99 era when C did not support mixed declarations and statements (all the variable declarations in a block / function had to come before any statements). In modern code you want to narrow down the scope of your variables as much as possible.
  • extract 4 to a named constant (a #define or an enum) and mark the arrays as having that length, too
  • extract the rand() % a + b to a randInt(a, b) function (Note that currently the end b is exclusive).
  • why is reps named that ? why not n_tests or test_counts ?

That's not what specifications are. Specifications outline the requirements of the kata directly, explicitly, and upfront, and the expected place for that is the description.

As per the official documentation, in the very first sentence under Writing a Kata Description, it states:

The kata description, created by the kata author, is a crucial part of every kata, presenting the task and all requirements to a user attempting it.

Specified in test cases

For a function that expects an essentially boolean output, it's a better practice to simply return just exactly that instead of a descriptive string value. For that matter, this is not at all specified in the description.

Approved

Approved

This is not a game I have played in real life, although I have played Mutations with someone, usually while on a long drive somewhere.

It is irrelevant that it is established ahead of time whether or not any player knows any or all of the words in the given subject list. They just do the best they can with their memory banks.

A player would not write out all the four-letter words they know before they play a game. First, it's probably way too many to bother with, and you will not even need most of them most of the time. Futhermore, they will not know which ones they will need, because new words will enter the game when their opponent uses a word from their own memory banks.

I hope that helps!