Practicing Prime Factors

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.