• These one liners are cool, but hard to read. Even though I recognize the ingenuity behind them, from the developer point of view, it's not really desirable.

  • @zruF You right that everyone probably knows, but you forgot that there might a bit of difference across countries. In my place, a single keystroke would directly aim for the letters. If we wanted to get numbers, we have to long-press it.

  • It's actually not tested. The whole case-insensitive thing is just to make things simple and focus on the main task: exclude
    Anyway, I've revised the description to mention about non-matches as well, just to make things clear. Thanks!

  • That's actually a good idea. When I first created the kata, I don't know how to cheat around the regex, until someone actually did. That's when I started to build some anti-cheats.

    The second anti-cheat is performing well so far. The reason your solution could pass was because there was a bug in the random string generator that prevented the word "code" and "war" from being generated.

    I don't know if asking for strings is better in terms of security, there might be some ways around it too. But for now, the current system is doing great.

    1. How is this an issue? it's not like the users are supposed to know what the anti-cheat are.
    2. The end goal is to make the Attempt secure from cheating. Whether they cheat in the sample test or not doesn't matter
    3. The first anti-cheat is actually in the preloaded, not in the sample test. There are no checks in the sample test. It's a big difference.
    4. They are different because they serve different purposes.
    • The first anti-cheat isn't supposed to be an anti-cheat. It's a preparation/complement for the real anti-cheat in the test cases. And it's necessary to put it in the preloaded code because you want to freeze the built-in objects before the users modified them first. You can cheat however you want in the sample test and you won't get an error.
    • The second anti-cheat is the real one, they're the one that checks whether you cheat or not based on your solution, and throw an error if you do so. That's why they have to be put in the test cases.
  • While matches should be case-insensitive, it's not currently clear whether non-matches should be as well. For example, should "CoDe" match or not? Is this being tested?

  • The anti-cheat is still not enough.

    Since you're doing the second anti-cheat by recreating the RegExp instance on test code anyway, why not just ask the user to provide the regex and flags string instead?

  • The anti-cheat check is different in the sample tests and the actual tests.

    • Added random tests
    • Added test cases for filter function that receives index and/or array arguments

    Anyway, this rework invalidates a LOT of submitted solutions because many of them rely on having the filter function with just one argument (value).

  • Find anonther kata to turn into code golf, and avoid the issues highlighted below - I will be one of the first to try it! ;-)

  • Too long: False should equal True
    

    Golf kata should really show the stats in the tests. We're not going to count the chars ourselves.

  • Ahhh okay, I thought you asked this question before completing the kata ^^

  • Loading more items...