Form vs. Function

As I’ve said before, for my small home project, where the most interesting work lies at the intersection of AppKit and a cross-platform C++ engine, I can’t write code the “unit test” way – writing the tests first – because those intersections are precisely what can’t be isolated from the entire application.

But I have changed some habits.

Now, I move the little snippets of logic I’ve written from their organically-grown locations to separate stand-alone functions.

These functions are grouped by purpose in their own files, such as UTF8 Functions.c or Geometry Translation Functions.m.

Because they aren’t classes, they need all their context passed in as parameters. This can be a pain in the ass, but it also prevents me from grouping too much functionality together; it would be too tedious to add all the necessary parameters.

It also means that I can access the logic directly from unit tests. I can try out in isolation all the little variations I need to really ensure the code is sound.

This works well for a small, home project. Splitting functionality out into lots of additional files may work less well in large-scale endeavors, where there are already hundreds of files in a project.

Then again, in such huge projects, the data model may be elaborate enough that there are more classes that, without modification, can be tested in isolation from AppKit (or each other).