Coding Is Like Cooking

I’m at XP2009 this week, the sun is shining, the sea is blue and the italians are disorganized. I’m having a great time so far. This morning I was at a workshop led by Danilo Sato and Francisco Trindade – ‘The lego lean game’. The idea was that we should learn about lean principles by playing with lego. I thought it was good fun, and we did learn quite a bit about pull, kanban and continuous improvement. I hope I will be able to run this simulation for some of my colleagues, I think it is a good practical way of learning using all the senses, not just reading books or listening to presentations. Much more kinesthetic.

As I wrote in a previous post, I am organising a workshop at XP2009 called “Test Driven Development: Performing Art”. I am very pleased to announce that I have four pairs of expert programmers willing to perform prepared Katas at it! You can read about it here. I am especially pleased that all the performers are experienced coders with previous involvement in coding dojos in places such as Stockholm, Linköping, London, São Paulo and Helsinki. I think we’re going to have a great afternoon on 27th May.

I am really interested to find out more about this concept of “clean code”, and in particular how it relates to programming language. To this end, I’m still chewing on KataArgs.

My latest idea is to start from Bob Martin’s Java implementation, and translate this as directly as possible into python. My idea is to then refactor it to be more pythonic, and see if it turns out looking anything like his Ruby implementation.

I have put up some code on launchpad, which is my attempt at a direct translation of the Java. It was really interesting to do, actually. Of course I had read the Java before, and followed along in the book all the steps to create it, but actually translating it made me understand the code on another level. When I tackled this Kata from scratch, I also got a much better understanding of it, but this was different.

One thing that jumped out at me was the error handling. It’s much more comprehensive than anything I’ve produced in my own solutions, and also compared with his Ruby solution. So I think it’s a bit misleading of him to say “I recently rewrote this in Ruby and it was 1/7 the size”. Of course it is smaller. It does less. Although to be fair, in a way it does more too…

One thing I found awkward to translate was the use of the enum for the list of error codes. Python doesn’t have a direct equivalent, being dynamic as it is. The other awkwardness was the Java iterator. In python iterators are built into the language, but don’t let you backtrack, or get the current index, unlike Java ones. I was surprised to find how extensively the tests rely on this functionality. To my mind, they probe the internals of the args parser too much.

By far my most interesting observation, though, is the one I want to explore more. This code is well written Java, but directly translated, it makes pretty poor python. Why is that? What, specifically, are the smells, and what are the antidote refactorings?

I will no doubt post more on what I find, (with the help of my friends at GothPy, of course)

I’m having fun with this KataArgs. In my last post, I took a closer look at Bob Martin’s Java and Ruby solutions to it. Since then, we have tackled this Kata at a couple of GothPy meetings. (My coding dojo; the code is here.)

Several of us did some more work on the kata individually after the meetings, and a lively discussion on our mailing list ensued. I also challenged the local Ruby user group Got.rb to have a go at it, and one person posted his solution there too.

It’s all good fun, anyway, and hopefully we’re all learning something about what we mean by “clean code” along the way.

Over Christmas I finished reading the book “Clean Code” by Robert C. Martin. I thoroughly recommend the book, which is highly practical, technical and well written. In it, Bob seeks to present the “Object Mentor school of clean code”, as he puts it, “in hideous detail”.

The book is full of code examples, clean and less clean, and detailed advice about how to transform the latter into the former. All the examples are written in Java, though, which leaves me wondering a little if “clean code” in the Object Mentor meaning of the word, looks the same in other languages.

In Chapter 14 of the book, there is a fully worked example of a little coding problem that I would call a code Kata. It’s a little program for parsing command line arguments. I know, there are loads of libraries that do this already. But never mind. It’s a non trivial problem yet small enough to code up fairly quickly. One thing that caught my attention was the footnote on page 200, just after he has presented his best Java solution to the Kata. “I recently rewrote this module in Ruby. It was 1/7th the size and had a subtly better structure.” So where is the code, Bob? What is this subtly better structure?

I had nothing better to do on Boxing Day than sit around and digest leftover-turkey-curry, so I sent a little mail to Bob asking him for the code. To my delight, I got a mail back only a few hours later, with a message that I was welcome to it, and the url to where he’d put it on github. Evidently Bob also had time on his hands on Boxing Day.

I have had a look at the Ruby code, and although my Ruby is fairly ropey, I think I can follow what it does (surely a sign of clean code?). The design is very similar to the Java version presented in the book, with a couple of finesses. (The next part of the post will make most sense if you first look at Bob’s Java version and Ruby version).

The first finesse I spotted, is that the Ruby version defines the argument “schema” in a much more readable fashion. Rather than “l,p#,d*” as in the Java version, it reads

parser = Args.expect do
   boolean "l"
   number "p"
   string "d"
 end

ie the program expects three flags, l,p, and d, indicating a boolean, number and string respectively. You can do this in Ruby but not Java because the language allows you to pass a code block to a method invocation. (the stuff between “do” and “end” is a code block, and the class “Args” has a method “expect”) I think the Ruby version is rather more readable, don’t you?

The second finesse I can see is that the argument marshallers dynamically add themselves to the parser, rather than being statically declared as in the Java version. This means that if you discover a new argument type that you want to support, in the Java version you have to crack open the code for Args.java and add a new case statement in the “parseSchemaElement” method, as well as adding the new argument marshaller class. In the Ruby version, you just add the new class, no need to modify an existing one. Bob invented the Open-Closed principle, so I guess it’s not so surprising to see him following it 🙂

So in Args.java:

private void parseSchemaElement(String element)
 throws ArgsException {
char elementId  = element.charAt(0);
String elementTail = element.substring(1);

// long if/else statement to construct all the marshallers
// cut for brevity
[...]
 else if (elementTail.equals("#"))
   marshallers.put(elementId, new IntegerArgumentMarshaller());
 else if (elementTail.equals("*"))
[...]

or in the Ruby code, each marshaller just tells the parser to add itself:

class NumberMarshaler
   Parser.add_declarator("number", self.name)
[...]

in the Parser class:

   def self.add_declarator(name, marshaler)
     method_text = "def #{name}(args) declare_arguments(args, #{marshaler}) end"
     Parser.module_eval(method_text)
   end

   def declare_arguments(args, marshaler)
     args.split(",").each {|name| @args[name] = marshaler.new}
   end

You can do this in Ruby but not Java, since in Ruby you can dynamically construct and execute arbitrary strings as code, and add methods to classes at runtime. (The string declared as “method_text” is constructed with the details of the new marshaler, then executed as Ruby code in the next line, by Parser.module_eval) This is an example of metaprogramming.

So it seems to me that the “subtly better structure” that Bob refers to in his footnote, is made possible by powerful language features of Ruby, such as metaprogramming and closures.

Of course my favourite programming language is Python, which also has these powerful language features. I am rather interested to see if I can come up with an equally clean solution in Python. I am also interested if any hotshot Java or Ruby programmers out there can improve on Bob’s solutions. To this end, I have added a description of this Kata to the catalogue on codingdojo.org. We had a go at it at our last GothPy meeting, without any great success, although I hope we might do better at a future meeting.

So please have a go at KataArgs and see if you can write some really really clean code. Do let me and the community on codingdojo.org know how you get on!