Code Audit

After a bit of working on things, I tried to write a little code that I just expected would work.  When what I tried didn’t exist yet on the other object, I got to thinking.  How many of the things that I just expect to be there are actually written?  This started a code audit that I initially hoped would be two or three days, but quickly turned into a two week long adventure.  This process was exactly as tedious and boring as you are probably imagining and involved several rather elaborate tables of check marks in my QubeKwest notebook.

As it turns out, a lot of my objects were missing a lot of the things I wanted them to have, and some other ones actually had completely different ways of doing the same thing.  (For example, a clone method instead of a copy constructor.)  That meant coding things that were missing, recoding things that I felt were weird, removing things that should never have been there in the first place, and adding tests to cover all of the things that changed.  While I was working on the various audits I was performing, I came up with a few new patterns I wanted in place and added them to my notes.  I even had a few columns for whether or not the files had all the JavaDocs I wanted them to have.

I’d like to say this was just a bit of “Hey, my Vector4 should have a static isEqual on it.” followed by coding it and calling it a day, but that’s not really how this process went at all.  Each time I’d bump into another thing that made me sad, I’d make another list with more check marks.  This in turn led me to wander into the code again from a different angle.  For example, once I’d added serialization to my math library, I realized that I originally wanted all of the functions to have both “static” and “with this” versions of all the math functions on all the objects, and that what I had was a bit of pot luck.  More check lists, more coding things, more writing tests to get code coverage back to where I want it.  This in turn inspired a test audit that made sure everything was tested correctly and where the tests themselves were named correctly (following the pattern I’d established anyway).

In the end, after weeks of checking out the code, working on new bits, typing JavaDocs, and adding tests for things I didn’t even realize were missing, I think the math and data packages are in a much better place.  That makes me happy on a deep fundamentally nerdy level, even if the process of getting there was sort of terrible to have gone through.