I spent all day coding in VBA for work. I’m creating Excel templates for data submissions. These templates need (at least I think they need) data validation routines that the people filling them out can run. Those routines will help prevent some data quality problems down the line.

The only tool for the job to code those routines is VBA, which is bar far the oldest language I code in on a regular basis. It is creaky, feature-limited, and its runtime is rather unstable. But if it works well enough for federal agencies (I have seen some data input forms in my time), it will work for me.

I used to think VBA was a trash language, and only trash code could be made from it. Once I learned I was stuck with it for certain tasks, though, I tried to make the most of it. Now I treat VBA like the proper object-oriented language it is. The result is that I have a lot more fun writing it, and I think that the code is easier to debug and modify in the future, too.

I keep my code clean. I keep methods as short as possible. I use long, descriptive names for methods, classes, and variables. I structure the code into classes extensively. I create classes for intermediate data structures to make other parts of my VBA code easier to understand. I refactor my code into numerous smaller classes when I find I am writing too many, or overly complex, private methods. I create and use factories to create and set up objects. I apply the principle of least privilege everywhere. I am pedantic about whether arguments are passed by reference or by value. I even use interfaces sometimes, too.

The result is code that is rigorously structured—perhaps hilariously so to the next person who will look at it. It is unlike any VBA code I have ever seen before, but it is probably a lot like many VB6 applications written in the early 2000s.