Log in

No account? Create an account
01 November 2013 @ 03:03 pm
Programming Class Week 3  
I'm growing increasingly concerned that the processes I'm learning in this class aren't necessarily transferable, though I suppose that's also true of people who spend a long time with one company and have to work with their proprietary systems. See, the class is about learning to program through making games, and to facilitate this, the teachers made a bare-bones GUI that we use to get images and text to appear. That's all well and good, but I'm running up against programming best practices here. Global variables are bad, but as near as I can tell, the GUI requires the use of global variables to function at all, since some of the functions for manipulating the GUI don't take any inputs. It give me an added impetus to make sure I understand the underlying principles rather than just blinding writing random things until it works.

This week was just learning more ways to manipulate the GUI, though I did learn that graphics coordinates are measured from the upper left of the plane rather than the lower left as one might expect, apparently because of the way old CRTs scanned--from top to bottom and left to right. The actual program was a stopwatch game--stop the stopwatch on a whole number, get a point--and the program dealt with storing the time in deciseconds as an integer, converting that into a minutes:seconds.deciseconds format, and then properly accounting for 60 seconds becoming a new minute, prevent ~.1 from awarding points due to improper rounding, and prevent the player from spamming the stop button on ~.0 to rack up their score.

It's the last one that was a bit concerning. The teachers suggested using a global boolean variable to track whether the stopwatch was running and preventing it from increasing the score if it wasn't, which, okay. The problem is that the GUI includes a timer.is_running() function to innately determine that, which I learned about by reading the documentation, so I just used that. Why didn't the teachers mention that, since they programmed the damn GUI themselves? You'd think that would be relevant in the first assignment where we learned how timers work.


In other news, I ran into a really odd situation during peer evaluation of last week's project. In the comments on the project, the guy who wrote it copyrighted it. I wouldn't have thought that this was more than an odd quirk of his personality--you're copyrighting a guess the number game? Sure, whatever, dude--except his code didn't even work. And I don't mean in some subtle way that required me to dig into it to figure it out, I mean that I pressed the "Random number 1-100" button and the program threw an error and quit. Not only that, but it was supposed to cycle through again after you ran out of guesses, so you could just keep playing over and over again if you want. His program didn't do that. It went through two cycles, but then threw an error and quit. Not only that, but getting the number correct on the last guess didn't properly credit you. The game just told you you lost and then started over, and then the second cycle was impossible to win because it errored out. I mean, this would have taken literally seconds to figure out from a cursory test, but he didn't do it.

I suppose this is how QA people feel all the time.

Edit: Poking around the class forums on the topic of global variables, I found this quote:
In event driven programming you need to keep state around between event handlers. Using global variables is the easiest way to do this at the beginning level. At the end of the course, I will discuss how you can migrate towards using better practices.

Global variables are bad because they lead to insidious problems that are often hard to track down in larger programs. In the small programs that we are writing here, they are often manageable, even if they are not really desirable (and still can lead to bugs).
So, we'll see how that turns out.
Current Mood: amusedamused
Current Music: Sjellos - Broken