An Observation On Coding Kata
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.
2 responses to "An Observation On Coding Kata"
Albert,
Agreed, using the KISS method for code versus being “compact and efficient” is a serious thing to consider. We need to consciously make that decision because as you said later on someone else is going to have to look at it and figure out what it really does. That is the maintenance factor, and if someone cannot easily get into the code and figure it out they will do one of two things; glaze over it and hope it works or they will trash it for their own more straightforward code.
You are correct in hinting that in today’s programming world we can have more explicit code written. Code and memory space are not at such a premium as they used to be years and years ago.
Sometimes it is better to spell it all out than to try to prove who cleaver you are. Yes, we should refactor code to make it better. But there is a boundary limit we may cross to which it makes the maintenance of that code much harder later on.
It’s a question of not out smarting ourselves. And that isn’t taught in these coding kata’s. We learn it by experience.
[Albert: Thank you, Jim.]
Excellent post.
[Albert: Thank you, Tom!]
However right you are and however your reworked version of the code shows the logic much better and is perfectly valid Ruby, your solution would not be considered good Ruby code by some as not being idiomatic enough (yes, there’s this kind of elitism among Ruby coders/programmers) – and yes, to some style means more than the issues you brought up, even if it means too heavy reliance on the built in capabilities (yes, one can choose some uber-compacted fancy-looking function or feature in their code without even understanding its workings or internals completely and the solution kind of works, but what if they don’t work and one needs to do some more work to “repair” the problem and has to dig into stuff that might even be more daunting than the mysterious workings of the fancy feature used in one’s code?).
[“..To some style means more than the issues you brought up” – Well, THAT is the issue. People willingly putting their personal quirks above the team (readability, maintainability) and business (quality, increased risks). That exactly is the problem I’m concerned about.]
One could say that since the line voted best is the one you quoted, the kata was for some smartasses who want to outmatz Matz or those same folks got the idea wrong and thought they were in some kind of Ruby-golf, and not just for people wanting to hone their Ruby skills. Jokes aside, I guess the question you really ask is “What is good or well-written code?” – is it some incomprehensible “idiomatic” noise or code that cleanly and clearly shows its purpose and intent? (spoiler: your solution as opposed to the “bestest” one-liner).
[Hmm.. First of all, I pointed to a pattern. If I ask any question that would be – what are the learning goals? If writing quality code is among them, then the voting went wrong.]
And what if some other as-advanced-as-you programming language user happens not to know the idiom you use?
[I have a solid programming background but I’m not even intermediate in Ruby, at least, as of yet. That’s why I’m doing Ruby kata :)
When I just started with coding, I had no idea what readability and maintainability were so important, and I didn’t want to waste my time on them. It’s with the experience I gained the realization. I guess in the context of coding kata there must be exercises exactly for that – reading and refactoring someone’s code in order to learn basics of maintainability.]
Some wise coding-related book (sorry, forgot the title and author) says that even if one’s code works well but is hard or impossible to understand, then it’s badly written, and in workplace-related cases where one’s code has to be dealt with by some other folks once one leaves the company one’s been working for leaving clean and clear code behind should be a sign of good practice, meaning that one thinks about and cares about his or her successors; otherwise, making one’s code seem obfuscated or difficult to follow might just as well be a means of concealing one’s lack of competence and the fact one cannot produce quality code. Zen of “some-programming-language”, anyone?
[Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
Or, better said: The Noble Art of Maintenance Programming]
(Sorry for this whiny and verbose rant, but this post really resonated with me and I wanted to add my 2 cents)
[Thank you for taking time to comment! Those were very valuable 2 cents :)
-Albert]