TDD Chess Game Part 7: Cleaning up the Bishop
I bet you thought I’d forgotten this series and the video-cast leg of my burgeoning multimedia empire, but fear not, because I’m back following a long vacation, bookended by content publication announcements. I took previous feedback to heart and increased the font size of the spreadsheet as I worked, and decided to make this video a little shorter. Trending closer to the 10 minute mark than 20 is partly selfish because the 20 minute videos take an absolutely staggering amount of time to produce in my video editing software, but I also think it might be more consumable this way. So, here’s what I accomplish:
- Extended test coverage on Bishop.GetMovesFrom() a bit.
- Cleaned up Bishop.GetMovesFrom().
- Moved Bishop to its own file.
And here are lessons to take away:
- It’s fun to be cute with your todo list, but the effect wears off after a break — better perhaps to keep it simple and descriptive.
- When you see duplication or repetition of patterns, ask yourself what’s the variable or variables in the repetition and see if you can parameterize it for an extracted method.
- Use the refactor phase to ask yourself, “how would this method read to someone who’d never seen this code before,” and to focus on how to make it clearer.
- This is pretty heavy on personal opinion, but I think favoring declarative (functional, Linq-y stuff) over imperative (loops and control flow) semantics promotes readability.
For me, the reason Linq-like/declarative syntax works better, is that it’s easier to reason about. I’ve found that a lot of what I like about code, or dislike about code, goes back to how formal proofs of correctness of programs work. If you would formally proof a loop, you’d need to define invariants, proof that the invariants holds, define conditions, transformations on them for each statement, etc. For the functional/declarative style, you’d only need to prove a simple mathematical function, which is much easier. There is no ordering involved, it’s just definition. This might sound a bit handwavy, but try… Read more »
I took a class once in grad school called “Formal Methods” or something where we did formal correctness proofs of functions that had like one or two control flow statements. The thing I remember most vividly about that was how it really drove home the concept of cyclomatic complexity and wanting to keep it to a minimum. I suppose if you reduce a method to a series of simple queries and/or commands that you can assume work properly, life becomes a whole lot easier from a formal perspective. I’ve seen that talk and a few others by Rich Hickey —… Read more »