Okay, after (mostly) wrapping up the map editor, I gotta say: I was pretty tuckered out. So I took a couple of days off, tried to pay off some of my sleep debt, wrote a couple of IMO pretty good articles, and just got back to work a couple of days ago. I wrote up a new schedule to ignore, and set to work on a couple of improvements to the engine which seemed relatively easy: First, improving the level drawing code to cut down on the rendering time, and second rewriting any classes necessary to improve the resolution to 1920×1080.
Well…
I think pretty much everyone who’s programmed professionally has had the experience of having to debug or reuse someone else’s code, looking it over, and wondering “what the FUCK was this guy thinking?” Now, in order to get some of this stuff working properly, I had to dig back into some of the parts of my program I consider ‘finished’. I’m sure you all can see where this is going.
What the FUCK was that guy thinking?
In a way it’s kind of reassuring. One wants to always be learning, always improving, and if what I’m seeing here is any indication, uh, I’ve improved a LOT.
The rest of this is gonna be programming talk. If you don’t care about programming, you may find this to be an excellent time to not read the rest of this article. Go catch up on doing that thing you like doing.
So here’s some of the things I’ve come to realize about programming– many are, I know, conventional wisdom when it comes to programming, but I try to accept such wisdom on a case by case basis instead of wholesale.
1. Seriously, don’t use literals if you can avoid it
I just had to search my entire code base for each instance of the number 25 and replace it with an initialize-once tileWidth/tileHeight value pulled from the game engine. Literals are okay for ratios, kind of, but even then it’s usually better to put that in a local variable with a descriptive name for readability’s sake. Speaking of which…
2. Shorter variable names are easier to read
For a long time I operated on the assumption that longer variable names tell you more and thus improve readability. Total specious bullshit. Long variable names make logical statements far more unwieldy and difficult to read. ‘lObjectPosition’ is NOT a better variable name than ‘p’. Use the shortest name you can that makes the purpose of the variable clear. That said, I’m still going to preface the use of all reference parameters with ‘r’ to signify that the scope of that variable extends beyond the current method, and similarly preface member variables with ‘m’ and static members with ‘s’ for the same reason. Conversely, similar prefaces used to denote variable type are purely silly in strongly typed languages, assuming you’re not using notepad as your IDE.
3. Don’t try to be clever for no good reason
Yeah, I know, even I won’t ever listen to this one. Still, if you ever catch me bitshifting instead of dividing by 2 again, you can slap me right in my stupid fucking face.