One thing at a time. Let's first write it out longhand:
>
```
def square_indexes(square_number)
result = []
first_row = square_number / 3
first_column = (square_number % 3) * 3
first_row.upto(first_row+2) do
| row |
first_column.upto(first_column+2) do
| col |
cell_number = row * 9 + col
result.push(cell_number)
end
end
result
end
```
That's a lot of code, and I'm afraid it won't work. And it doesn't:
>
```
1) Failure:
test_square_four(TC_MyTest) [./sudokutest.rb:31]:
<[39, 40, 41, 48, 49, 50, 57, 59, 59]> expected but was
<[12, 13, 14, 21, 22, 23, 30, 31, 32]>.
```
We see that it has started in row 1, not row 4 as it should have, but that it is taking the right corresponding cells after that incorrect start. So the row_number init is wrong.
Now, this might have been a good time to just throw the code away and start over, which is a pretty good trick. If I had felt the need to debug, I'd have tried to start over instead, since that method was pretty weird. But I see exactly what the bug is—I think—so I'll just fix it. If it doesn't work, I'll start over.
“OK, Sudoku [1]”
This is the type of programmer [2] I was talking about yesterday—not only is he unsure about 14 lines (and makes it out to sound like it's thousands of lines) of a dynamic programming langauge (Ruby [3] in this case), but he's not even clear he understands the bug in the code.
Also, the “crutch” this programmer uses is “unit testing,” which to me (because the culture is totally alien to my way of thinking [4]), translates to “let us write a ton of code to catch bugs that in a statically typed language, the compiler would catch.”
I don't know if that programmer really thinks that way, is just playing a “I don't know what I'm doing” type of programmer for the sake of demonstration, or it's a serious case of “the culture is totally alien to my way of thinking” but I'm finding his presentation of his programming methodology extremely annoying.
I choose to say “we'll need” here to emphasize that implementing those methods in yesterday's spike was a violation of YAGNI (You Ain't Gonna Need It), the rule that says not to implement things just because you need them.
“Moving On With Sudoku [5]”
I don't think YAGNI (You Aren't Gonna Need It) [6] doesn't mean “not to implement things just because you need them.” But I could be wrong, as I think Ron Jeffires [7] (who's writing these annoying articles) coined the term. And even if he is right, he's giving excuses for not following his own advice.
Alien cultures indeed.
And comments like:
… I have to figure out which row number a cell is in, which column, and which square. Each of those is a bunch of integer divides and modular arithmetic, which I have a good chance of getting wrong …
…
Maybe it means I've thought too much about this, or that I'm following my anticipation too much.
…
Here we go. Hold on, that was a lot of code, ten or so lines … [But he's written about a bazillion lines of code implementing test cases, but I guess those don't count. —Editor]
“Moving On With Sudoku [8]”
Isn't helping my confidence with his coding skills any. Is it any wonder I consider dynamic programming afficiandos as sloppy thinkers [9]? And the bit about getting divides and modular arithmetic wrong? That's just … [DELETED-wrong! You are not a programmer if you don't understand modular arithmatic-DELETED] alien to my way of thinking.
Okay, I think I'll stop reading this now.
[1] http://xprogramming.com/xpmag/OkSudoku
[5] http://xprogramming.com/xpmag/Sudoku2
[6] http://c2.com/cgi/wiki?YouArentGonnaNeedIt
[7] http://c2.com/cgi/wiki?RonJeffries