Pragmatically Function, Ruthlessly Refined
So far, my model code weighs in at just over 150 lines. The tests to verify functionality are just over 225 lines. That means that so far my model is about 2/3 the length of the tests that support it. A lot of those tests are test data rather than code, but that’s definitely the best ratio of tests to code that I’ve maintained so far.
I’ve also been learning a lot of useful tricks in Swift. So far my favorite is leaning on type inference to know that ["a", "b", "c"] should be inferred to be Set<String>(["a", "b", "c"]) if the argument is expecting a set. Trying to go all in on Swift style, I’ve been making use of anything I possibly can to reduce line length that doesn’t kill readability, particularly avoiding using self unless required, leaving out inferred type declarations and so on. The downside to all of these shortcuts is they increase my dependance on the compiler to know the exact state of my code at a glance. I’m very interested to see if my future self is annoyed by or pleased with my decisions. I’ve also started dabbling with generics, which will hopefully help me maintain isolation of layers of my code by not needing to know specific details such as the fact I’m using a HexGrid<T> that stores HexCell<T> which contain, among other things, public var entity: T?. This means that I now have nothing defined about what the cells will eventually contain, and when I do define that, it won’t require any changes to the HexGrid or HexCell classes.
As I move out of model-land and into view land, keeping my clean Swift-y style is likely going to take a hit or two because I’ll be interacting with Objective-C libraries and classes, but I’m looking forward to the challenge of trying to keep Swiftlint happy and keep my style clean while doing that.