Kata

It is not clear from description that it is entire code length. I belive it should be fixed, or even modified to be regexp length, cause not passing tests with re = ... while tests are ok with re=... is kinda confusing.

Hi there, I'm sorry if the description wasn't clear for you. That's what code golfing is always about; they measure your entire code length, not a specific part of your code.

And if I may guess, it seems like you wrote something other than regex, because there's no way your code will be detected as 60 characters when your regex pattern is only 23 characters.

Thanks!

What's wrong with assert(true) ? And what's so special about tests that there are test cases without assertions?

What's wrong with assert(true)

Nothing, I just didn't think about it xD

what's so special about tests that there are test cases without assertions?

Not sure what you're trying to say with that, I was just trying to write an optional test, where something is actually being checked but you wouldn't fail if the assertion fails.

And what's so special about tests that there are test cases without assertions?

Blocks without assertions are normally interpreted as failed tests. It "works" thanks to a bug which cannot be fixed because hundreds of katas will break.

Or was it a question for the author meaning "why are there such tests at all"?

@FArekkusu Yeah, I'm not sure if he's asking you or me.

Yes I was probably not clear enough. I was asking why are there tests withot assertions at all? Now I see it's about an "optional test". It's true that testing frameworks generally do not support such thing too well, and I do not like "optional tests" either, but meh, not going to fight about his.

Now the question would be, why Basic Tests and sample tests have no assertions.

OH SHOOT! So that's what you were guys talking about. I'm sorry, I totally didn't realize that I didn't use assertions in the sample & basic test. I think I needed some sleep xD.

Anyway, it's been fixed now, thanks!

Yeah, I was thinking about doing that. But I'm afraid it would make the test predictable.

Issue part: no, it's not outdated. Maybe you misunderstood that as a requirement. It's just an additional check to see whether you also beat the author's solution, which was 20 characters. Just a hidden bonus challenge.

Suggestion part: You right, some aren't printable, and I also not quite sure how to handle it. If I log the charcode, and the character isn't printable, wouldn't it become ambigious?

Something like: Testing for (charCode: 25), it kinda implies it's testing "charcode: 25" Whereas, if there is just blank: Testing for , you can know for sure that it is a whitespace or an unprintable character, which shouldn't be matched anyway.

And how do I add them to the sample test if they are unprintable? Well I can use String.fromCharCode, but wouldn't that add an additional complexity from the user perspective?

If you have better ideas, feel free to share.

(thing is, for now, I'm failing some tests but I have no idea why since the char isn't printable... :/ )

Edit: damn you... I was matching up to 127 because of the description. Not sure if this trap is acceptable or not... (I guess it is...)

Edit²: 18 chars ;p

testing: Adding quotes can also create a new problem. What if the string is unprintable? you could get testing for "".... How do you know that is an empty string, a whitespace, or a quote (since the input can be a literal quote)? You can figure it out of course, but still, it can be confusing.

hidden challenge: Yeah, I agree it's quite ambigious. I've added a text "Bonus Point" next to it for clarity.

sample test: good point, but I think a better approach would be to clarify it upfront in the description that the input could be unprintable. But still, it could be unnecessary because it's been mentioned that the input range is 0-255.

I was matching up to 127

Lol what? Are you saying that your regex matched the entire printable ASCII codes? (32-127) xD

Btw, I've modified the assertion message to also tell the charcode. It does so in a different line and with some verbocity to make it clear that it's an addditional information. Thanks!

Are you saying that your regex matched the entire printable ASCII codes? (32-127) xD>

no, but I was matching 127, which isn't printable, while everything else was correct. So it was rather tedious to get what was the problem (since I didn't have the charcode on hand... :p )

thx for the updates

Oh haha, you're welcome.

Well, ASCII has couple variations. The original one only has 7 bits. The 8 bits one is an extended version. It's not like ASCII only has one definiton. The Linux manpages define them as 7-bit code. So saying ASCII is 7 bits or 8 bits are both correct, likewise, saying that all ASCII symbols in total are 33 is also correct.

Later in the description is to clarify which version of ASCII that should be used.

I mean alphanumeric characters. They are in ASCII, so the first sentence contradicts the exceptions introduced further in the description.

Oh, I guess that's another "multiple definition" problems. In literacy, letters are considered as symbols. But in regex, we usually use "symbols" to refer to special characters / non-alphanumeric characters. If we want to refer to any character, we just use "character", not "symbol".

Any source where "symbol" is used in that sense? Does that definition not include control characters?

I'm afraid I don't have a concrete source for that, maybe it's just a misunderstanding in my place.

Anyway, let's say I agree with you, what would be the correct replacement for "symbol"? "special character"?

Maybe just "matches any character from the following list" or something like that?

That would work just fine for the description, but not for the title (too long). And what about the message in the test cases? "Should match for these characters"? (not so helpful)

I've replaced all occurences of "Symbols" with "Special Characters". I also added a short definition about what constitutes as special character. I hope it's clearer now. Thanks for raising this issue.

No it didn't? If I missed a quote, the syntax would be invalid. Or are you suggesting to wrap the input in quotes? That would be ambigious whether the input is a quote or a whitespace.

Got it!