No, this kata needs retirement. Hidden specs, unclear specs, very annoying sanity checks ...

The kata needs random tests.

Also, the kata needs chai.config.truncateThreshold = 0.

How would that even work anyway?

You can't have a valid string with extra letters, because the presence of extra letters means you can't say anything about the validity of any matches.

The kata needs a little precision like: "You can assume that the input string s is always valid and every letter matches a password.".

What if you give a valid string, with extra letters? Maybe part of another test...?

If you feed PostgreSQL an array (of actual type array!), it returns to you a string, with {} characters instead of [], and with numbers with preceding zeroes in it ?!?

I'll forgive it the wrong quotes; I expect that from SQL and JSON.parse should support them.

Otherwise, if it actually does that (and I have trouble imagining this), imagine my opinion of PostgreSQL at this moment.

And replacing JSON.parse with eval does not feel like an innovation. It feels .. dirty. :P

This test has not been thought with the initial idea of discouraging JSON.parse.

This test comes from a real case:
I have a column of type array inside a PostgreSql table. Array's format in Postgre is exactly what we have in the test input.

The best practice, is the one that helps you solving a specific problem efficiently. If JSON.parse can not work here, then the best idea is not using JSON.parse, but to innovate :)

Discouraging JSON.parse in favour of eval or new Function does not seem like the best idea.

Where did you get this piece of information from? JS files are typically minified and gzipped anyway so this makes no sense. Not even JSstandard mentions it. It must have been some other random people conjuring up excuses without citations so they can feel justified not following the most authoritative semi-standard :P

That's exactly my point !!!! This piece of information comes from a man on StackOverflow who agrees about this standard and made his own interpretation depending on his own experience with other developers inside a group. His argument can be valid if you don't have to minify your js file, otherwise it doesn't make any sense like we said (https://stackoverflow.com/questions/22782677/coding-style-in-javascript-why-prefer-2-spaces-not-4-spaces).

Also, if you're coding inside CW, it also defaults to using 2 spaces as indent (backspace and opening new lines. Tabs are ignored here).

If your standard does not give me a solid and unbeatable reason to use it, that means i can have my own, since every solution provided will have its specific standard, or no standard at all.
I understand your point of conforming to standards, what I am trying to say is that, it's not the absolute way to do it.

They're basically the same in this case:

https://stackoverflow.com/a/4599946

But using eval is simpler, so I used that.

Please also tick Mark issue as resolved if the issue is resolved :)

That's an excellent idea, thanks.

Thanks, changed. In the future, I will do myself every kata i create, like a real user.

Interesting result, but question, why did you use eval in this situation, instead of a function?

Also, no random tests

the main reason this standard has been fixed is to save 4% on the file size

Where did you get this piece of information from? JS files are typically minified and gzipped anyway so this makes no sense. Not even JSstandard mentions it. It must have been some other random people conjuring up excuses without citations so they can feel justified not following the most authoritative semi-standard :P

"The unit of indentation is four spaces. Use of tabs should be avoided because (as of this writing in the 21st Century) there still is not a standard for the placement of tabstops. The use of spaces can produce a larger filesize, but the size is not significant over local networks, and the difference is eliminated by minification."

Also, if you're coding inside CW, it also defaults to using 2 spaces as indent (backspace and opening new lines. Tabs are ignored here).