13 Easy Ways For Making Your Very Own Collection Of Bugs

We programmers are nice folks. Instead of calling things “error that I made” we’ve found this nice little word “bug” to represent our mistakes. It’s hard to admit making a mistake or an error (especially when it’s “Windows error, not my bug”), but admitting making a bug is bit more likely (at least for those who stop saying “it’s not a bug, it’s a feature”)

Anyway. Here’s some of my favorite ways of creating bugs in games:

  1. Don’t use functions (or objects and classes, or anything that sounds “too big for my current small challenge right now”)
  2. Use tons of IFs.
  3. Copy & paste code.
  4. Use principle of adding “special cases just to deal this situation” to your code.
  5. Edit the wrong files.
  6. Add tons of changes and then test all them once (instead of testing each new update after the change is done).
  7. Try coding 3 to 7 different issues simultaneously (instead of one)
  8. Change some parts of code for testing “just for a while” and then don’t document why you did this.
  9. Forget testing in Release mode, Debug mode will be enough. (Not exactly helping to create a bug, but will help spotting some)
  10. Leave parts of code open (and of course undocumented) and take a 2 week break
  11. Start something big just before you are about to end for the day (and you will find yourself spending the next morning figuring out what was going on)
  12. Use some of your previously created code in your current game (and notice how many bugs there lies)
  13. Use the shortest possible variable names (“c, cc, i, h, hiryb” instead of count, creditCard, i, height, heIsRockingYourBoat). Always.

You agree, disagree? How about adding your favorite ways for creating bugs?

8 thoughts on “13 Easy Ways For Making Your Very Own Collection Of Bugs

  1. re: no indenting: Agreed.
    magic numbers = inline constants

  2. Magic numbers?

    Regarding that 4th point of yours: at least it’s much better than 500 lines long functions *without* indenting :)

  3. - Change code for testing and forget to change it back.
    - Use magic numbers.
    - Don’t properly test complex branching code.
    - Write functions at least 500 lines long with tons of indenting.

  4. http://en.wikipedia.org/wiki/Software_bug

    Actually the modern use of the term Bug may actually refer to a moth in a electromechanical computer in 1947. The etymology in that wiki link is an interesting read.

  5. @David: “faster” is so… relative. I feel that doing a quick test after adding one feature should be something to always do. Doing this minimal test saves tons of work in a long run.

    People who can do unit tests (at least for some important parts) are in great position.

    In doing networking stuff, I’ve experienced several crash-bugs (that were quite easy to fix though) by not testing all the time.

    @Fili: good point. although I must say that my own thinking goes somewhere in the middle. I find it quite useless to test in release mode all the time… maybe “every now and then” is fine, but I would hope to test more than “just before the release”. I try focus on good coding habits (like initializing variables always…)

    @MC: I’m guilty of all of them. Some more than the doctor orders… (4, 5, 6 and for example I did within about 2 weeks… and I’m supposed to have like 10+ years solid programming experience..)

  6. You should test in Release as often as possible. Release can help you find uninitialized variables (initialized with 0 automatically on Debug), out of bounds arrays and some other stuff. It’s easier to fix a bug when you make it that at the end, when you have 500 other bugs in your app.
    BTW, I’m not kidding with the 500 bugs. In the beta-testing phase of our games it’s common to have 3-400 bugs open at the same time, with over 1000 total bugs fixed in the end. Hard to believe, huh?

  7. Nice post. i’m guilty of some of those points

  8. I agree with all of those except maybe 6 and 9.
    #6: While you can introduce more bugs at once when you add a lot at once, you can also develop faster. Of course, it depends on your definition of “A lot” of code. I know some programmers I have helped over the years who insist you need to compile and test with every new line of code, or sometimes every function added.

    #9: While testing in release mode is necessary, it is better to test in debug mode except when you’re getting close to release (hence why it is called release mode.) Otherwise debugging issues is…well, harder to debug! (Assuming your taking advantage of the very powerful debug features in your IDE!)