Bad Habits in Udacity's HTML5 Game Development: An Example

[elfs]

This screenshot more or less perfectly illustrates what I consider wrong with the Udacity HTML5 game development class.  We’re in the middle of a routine for drawing sprites to the screen, and so far this particular lesson, on asset atlasses and sprite packing and all the rest, has been fine, but there’s something in this particular code that makes me twitch hard.    Take a look at the “hlf” object created in the middle of this function.  What is it doing?

It’s doing nothing.  It’s not a transformation.  It’s not analysis.  It’s not functional.  It’s just a renaming of one variable (“center of x”) to another (“half of x”).  It doesn’t even help the user understand what’s going on.

But it’s also doing something else.  It’s creating a new object in the context of this function.  That object goes onto the heap until the Javascript VM performs garbage collection, at which point the entire VM pauses to make sure no references are tampered with as it cleans up.  Different VMs (V8, SpiderMonkey, Chakra, etc.) perform garbage collection on different criteria, but all monitor memory growth, watch for times when memory usage exceeds a certain point, and perform routine garbage collection on an interval.  Every HTML5 game designer in her right mind should be doing absolutely everything she can to prevent the garbage collector from triggering, and if it must, giving it as little as possible to clean up.  A long VM pause is going to make one hell of a mess of your jealously protected 30 frames per second, and depending upon the tightness of your code it may throw off timing routines as well.  Remember: setTimeout(func, 60) doesn’t promise to run func exactly 60 milliseconds later; it promises to run func “as soon as possible” after 60 milliseconds has passed.  Relying on that while throwing in possible ~100 millisecond garbage collection pauses is a sure recipe for failure.

I understand that this is a basic course, and it’s going to be missing a lot of details.  Memoization and hyper-functional up-front calculations are fairly advanced subjects.  But there’s a difference between not covering advanced topics and actively teaching students a bad habit.

Comments

[prock.livejournal.com]

The code declares two new references to existing data without an apparent improvement in readability, accessibility or clarity.

Using aliases for the purposes of documentation is a fairly standard practice.

In the code snippet provided, presumably hlf is an alias for the center of the sprite, indicating that we are using half it's width and height to position the sprite. I could certainly take issue with the use of variable names here. It might be that the person who wrote the code struggled to figure out what cx/cy where, and when they did, they chose to document that in the code. It's not the best job I've seen at doing that, but that is certainly a standard idiom that used commonly in programming. In fact, I'll be happy to admit that I used the hlf identifier as a hint when trying and figure out what the code was doing. As an identifier, hlf carries more semantic information than cx/cy.

I will admit, I have, on occasion, created my own version of object, either so I can extend it with additional methods, or reformat the data so that it make more sense internal to the application I'm developing.

In this case, the object was not extended, but rather narrowed, something which is a not unreasonable thing to do.