It certainly does help testers to understand code and be able to code on their own. So I welcome “coding kata” movement. In fact, I can recommend some good ones, like Coding Games. Not only to testers and wanna be programmers, also to teenagers and their parents.

Exercises in a context, presented in a spectacular way!

However, I couldn’t help but notice a pattern.

While in the nutshell this exercise teaches loops and sorting, this code snippet was voted as the best one (the language is Ruby).

It is certainly compact and “elegant” from some point of view.

Back in my days, I used to write resident code in 80×86 Assembly, also striving to make every byte count, and every instruction as optimal as possible.

But even then, I often started with a basic, straight forward logic. Made sure it does what it’s intended to do, and doesn’t do anything unwanted. And only then I’d optimize and refactor.

Nowadays, code size and performance are not as much concerning as stability and maintainability. When looking at that one-liner I can’t help but wonder.

• What about mental effort a reader has to take to unpack the code into separate statements? That effort will greatly reduce the programmers cognitive ability. It’s also a distraction.
• What about debugging? It is impossible to execute instructions step by step in this form.
• What about logging? Without breaking up the line one cannot insert log statements.

These are not only my concerns based on my reach automation experiences. I heard enough of similar comments during code reviews.

Simple, self-explanatory code is one of little quality assurance techniques that make a difference.

And I suggest the following version for this exercise.