So for the last couple of weeks I’ve been practicing the binary search algorithm, as laid out by Dave Thomas here. I’ve done both iterative and recursive variations in C++ and then in C. I love the value of katas for learning new languages and features. I know both C++ and C, but doing this simple problem in both programs allowed me to work on learning new areas in each. First, in C++ I took the time to use the standard template library (stl), because I’m not very familiar with it. I just used vectors in my tests, but it helped me to become familiar with the stl documentation and the concepts of iterators as used in the stl.
Next, I did the same variations in C. This was fun because C is so basic, and it’s been a long time since I coded in straight C. You don’t worry about concepts like objects or functional programming (though they may help you think about the problem). It gets you really close to the underlying physical model of computation. You’re forced to think more about how the memory is laid out, and how the algorithm takes advantage of that, whereas with C++ and the stl the whole problem and the solution are more abstract, just slightly more removed from hardware.
In addition to the languages themselves, it’s also a chance to practice my use of tools. I used the work to hone my skills in vim, to understand our build system at work more fully, and to consider testing frameworks.
Uncle Bob’s tweet from a few weeks opened my eyes to the value of practice in honing my development skills, and led me to read a lot more about practicing and code katas. One of the things I love about having a kata, like the prime factors kata, is that you can focus on different skills and techniques each time through. You can do it in different languages, with different testing frameworks, using different text editors or build systems, on different operating systems, etc. I’ve done it a few times in the last few weeks, mostly in C++ (my current language for work projects). But I’ve used Visual Studio, vim, my work’s build environment, and other variations. I still haven’t used a decent testing framework, but that’s one I want to add.
Having gone through the prime factors kata a few times now, there are some changes that I feel should really be made near the end. Ok, the rest of this post isn’t going to make much sense until you at least read through the prime factors kata. Go do it now.
Commenters rightly pointed out that having the additional
if (n > 1)
clause added in test 4 isn’t intuitive and violates the TDD principle of just adding enough code to make the tests pass. But they then added the caveat that without it the step to loops and the candidate variable in test 7 is pretty big for the refactoring step, mostly in terms of the mental leap. I agree.
But if you really do the easiest thing you can as you add tests, you don’t run into that problem at all. The key is when you get to the test for finding the prime factors of 9 (i.e. the seventh test in the slides). The slides have you first creating a variable, candidate, to represent the number 2. This may makes sense as a refactoring step done before writing this test, but lets ignore that for now, and assume you haven’t done it. Then the easiest way to get the seventh test passing is just to copy the entire while loop below itself and change the 2’s to 3’s. Not only is that dead simple (Ctrl-C, Ctrl-V), it also makes the following steps much more obvious. At this point it’s easy to see how important the candidate variable is, so you create it, and increment it between the two while loops. Then the two while loops are identical so you just nest them inside another while loop. The remaining refactoring work to for loops is the same as the slides.