I don’t have a CS degree. I learned programming from books, starting with QBasic in high school, then C, then enough C++ to scare me off programming for a few years, and finally the siren’s call of C# has lured me back. My education is lacking in some areas, so I try to make up for this by reading as much as possible. A couple of my favorite books are Object-Oriented Design Heuristics and Code Complete.
As part of my ongoing research, I listened to Jonathan Blow’s talk at Berkeley last month. It was eye-opening, and packed with great advice, but more importantly, it was reassuring.
After listening, I felt less ashamed of my “shooting from the hip” approach to programming. I don’t write formal specs, I just code incrementally and refactor as needed. When the project is done, parts are pretty messy. There are always a few things I would have done differently if I had time to undertake a major refactoring, but hey, the game works, and it’s done.
Why was this talk reassuring? Jon is going out on a limb to challenge some computer science orthodoxy. Despite my not having taken classes in programming, I’ve been exposed to plenty of this in books and online discussions. There is such a value placed on the Right Way to program something that the cost to program it is often overlooked. The Right Way can be wrong. The heresy! And he’s right.
Here are the main points I took home from the talk:
1. A generalized system is usually worse than a specific system.
There are times when I’m programming a new feature, and an angel on my shoulder says, “Hey, you’ll need this for more than one thing. Let’s make it just a bit more abstract, and not so closely tied to this one class. Remember loose coupling? Eat your peas and carrots.”
I’ve heard to this practice referred to as “gold plating” … adding something you MIGHT need later, but don’t need NOW. The advantages of an abstract, general solution? I’m not sure, but it seems to look nicer. The cost? a) time to think about potential other situations to accommodate, b) more time to code these solutions, c) more cases to test for bugs, d) the method now has a name like ProcessInput() which gives no clue as to what it does.
Jon responds to one of the comments on his post on the talk with: “Why don’t you just, you know, let the two objects communicate?” I need a bronze engraving of this.
At some point during development of Escape Goat, I decided it would be good to have two projects: the game, and the “engine.” All the low-level stuff like sprites, player input, and audio could go into the engine, and the stuff specific to the game, well that belongs in the game. What a mistake. Now I have all kinds of interface definitions just so the engine can operate without knowledge of the game’s types. Which means updating everything in multiple places for every interface change. (Lately, I have been discretely smuggling classes from the engine into the game project.) The costs have been real. The benefits? Who knows, I can’t think of one writing this here and now.
Imprinted in my mind now: Start with the simple, specific solution, no matter what coupling this might introduce. And if enough parts of the system use this solution, think about refactoring it into something general.
You can always go from two similar specifics to one general. It can wait.
2. Don’t optimize early on.
37Signals likes to say “Ignore the details early on.” I think this is one of those details. Wait until you have performance problems, then find the parts of the code that are slow and work on them for a while.
I have a more positive Escape Goat anecdote for this one.
Case in point: Garbage collection. My current build generates tons of garbage. I haven’ t even profiled it, but it’s going to be nasty if I do. Each room change builds a new copy of everything in the room, and most room actors are composites of some very complex types. When a TNT keg explodes, every debris particle gets freshly minted, then discarded 30 frames later to be gobbled up by the GC. Horrible practice, right? I should be pooling and reusing these, right? Nah, I’ll pass. There is zero noticeable performance hit, because my game is a puzzle platformer with a few hundred actors on-screen, not a bullet hell shmup with thousands. The pooling system could have taken me a week, and now I get to spend the week on other stuff.
3. Use straight-line code instead of function calls for single instances.
This one hits close to home because one of my favorite programming principles used to be, “When you’re going to add a comment describing what the next bit of code does, instead make it into its own function, with the comment as the function name.” I loved this principle so much that it’s my only programming tip tweet.
And… I’m not letting it go just yet. I still think this is valuable when designing new code, because in the function call you decide what gets passed in, and it narrows the scope of the problem to a few key variables. The cost of doing business this way is that you end up with a bunch of small functions that are only used in one place, and you have to bounce around when stepping through code.
My compromise? I’ll keep doing this, but after the code is working, I’ll re-inline those functions back to the parent method. I like solving problems in the safety of a smaller scope, but once it’s working, it’s back to the Mega Function for you. Pro Tip: You can even simulate the function call with an opening curly brace to open a new scope.
Bottom line: There is a beauty in some ugly code, when you can see the time saved by not handcrafting the ideal, elegant solution.
