I think as far as "best practices" are concerned, it's what the code actually does that matters when voting, not the actual style of code employed when writing the solution.

I don't think people are marking submissions as "clever" because someone deleted whitespace/newlines and shortened 3 lines of code into 1, they're voting "clever" because what the code is doing is clever - regardless of syntax, style and other cruft. It just so happens that in a lot of cases, particularly these easier problems, "clever" solutions consist of one line. In addition a lot of people seem to be going for code golf, though there's no benefit of doing that.

In an actual codebase I think that, while most people would spread this snippet of code out, it would nonetheless be considered "best practice".

Not that there's anything wrong with that answer, but I fail to see why it gets upvoted 7 times as best practice compared to others.
I'd rather have this one (http://www.codewars.com/kata/reviews/53952000369894e4f10007ab/groups/539823dfc729da37a4000374) which is more readable (at least in JavaScript where there's a fair amount of syntactic noise. In other more expressive languages (e.g. a ML), even a one-liner would be acceptable and best practice.

Anyways, just pointing out: while this is perfectly correct (and fine for a trivial exercise like this one), I'd rather not people consider it too "best practice" (same for http://www.codewars.com/kata/reviews/53952000369894e4f10007ab/groups/53952f8ca3ba5f5632000f95).

Nope, this definitely does not qualify as best practices! It's incredibly presumptuous about the object values, so anything too far outside of what was explicitly tested in this kata would probably fail.

Just having some fun with it :-)

I second that as well. 6 kyu seems fair.

Think this could be improved or hardened in a number of ways:

• supporting dashed words (e.g. 'Jean-Pierre')
• supporting specially-cased words (e.g. 'iTunes') where casing has to be preserved (whereas in the current status, the minor words are expected to be lowercase)
• supporting very long lists of minor words (if the array is excessively long, lookups might become painful and it doesn't scale for a solution where this would be meant to be seriously run on a large corpus with many exceptions).

Last point it a bit too specific, but the first 2 could make it more difficult yet acceptable (and worthy of 4kyu, which I don't think it is at the moment, I'd rather rate it 5 or 6 in the current state).

I don't think this should be a 4kyu, or even a 5. Maybe a 6.

Maybe it varies on what you background is, but to me that looks like a programming 101 exercise that we'd usually give to students as part of their exams after their first month. It's not entirely straightforward and there are many ways to approach it (but codewars doesn't rate that), but it's not really as difficult as what I'd rate a 4.

5 kyu seems a bit high for that one. 6 kyu maybe?

I'd recommend changing the test cases to directly be:

Test.assertEquals(hamming(1), 1);
Test.assertEquals(hamming(2), 2);
// ...and so forth

It's self explanatory enough, and at least it gives me back the value returned by the hamming function. Doesn't happen with expect().

Yeah I'd agree this should be a general case question.

This seems rather useless as a kata in the current stand, barely more than an intro to calc and programming. Or maybe I missed something...