Chess TDD 46: En Passant Expiration Date
This installment of Chess TDD was another episode focused on en passant. It’s been a while since I was in this code base. I’d been on the road a lot and without my main development/recording rig. But now I’m back and was able to take the opportunity to record a little Chess TDD ahead of my wedding next week. This episode went pretty smoothly. I cleaned up a method from last time that had become unwieldy and then got the next acceptance test to pass without any flailing. Not bad for so much time between episodes!
What I accomplish in this clip:
- Refactored the Board.MovePiece method away from mounting ickiness.
- Implemented functionality to prevent en passant from lasting beyond one turn.
Here are some lessons to take away:
- When extracting methods during a refactor, if you have a hard time giving the new method a coherent name, it might be a sign that you’ve selected non-cohesive functionality to extract.
- Spend a few extra brain cycles contemplating the names that you give things. This investment will pay off because it’s easier to give things good names when their functionality is fresh in your mind.
- If you start to have code that no longer seems to belong in a class, make sure you’re keeping that visible to yourself as you go so that you can have a nice cue for refactoring.
- Take care to keep communication between methods and classes at an appropriate level of abstraction. Make sure they’re communicating in obvious domain concepts.
On the brackets after control flow statements: I totally get the reasoning on why you don’t use them. It’s akin to the reasoning for not using regions as well. Up until two months ago I was all for eliminating all the brackets as well. A coworker pointed out though that it’s much safer in a shared code base to use them regardless of your intention. It’s consistent with the rest of the language and so takes a bit less cognitive overhead to just slip into the bounds of brackets while reading. While it would be a goal to have only… Read more »
I think your coworker’s argument is the standard, iconic argument for the practice. It’s certainly the one I’d heard many times, back when I used to include the bracket. In the Chess TDD series, it’s a moot point, since I’m the only player and it just boils down to my own defacto standards and my reasons for them. But there’s an interesting thing here (and a blog post I may write). The argument in favor of including the brackets essentially amounts to “you should do something extra because your fellow developers are careless and need you to notch the safety… Read more »
I agree that the philosophical portion of this is way more interesting. Often times decisions can come down to, do I trust my fellow developers? I also totally agree with the no brackets being a pretty weak excuse to introduce any defects. I don’t think that having the brackets really qualifies as doing anything extra. I’m just consistently evaluating my own coding styles so as to make it as difficult as possible to misconstrue anything in my code and this is one of those asinine micro decisions I mull over now and then. Currently I lean toward brackets, but not… Read more »
Amen to constantly re-evaluating your approach. I’m the same way (which, as an aside, often makes me uncomfortable working for a long time against a “coding standard” — it makes this iteration difficult)