Comments on: 13 Easy Ways For Making Your Very Own Collection Of Bugs http://www.gameproducer.net/2010/07/04/13-easy-ways-for-making-your-very-own-collection-of-bugs/ I bake games. Indie style. Thu, 16 May 2013 13:23:44 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Jake Birkett http://www.gameproducer.net/2010/07/04/13-easy-ways-for-making-your-very-own-collection-of-bugs/comment-page-1/#comment-141166 Jake Birkett Mon, 05 Jul 2010 15:43:20 +0000 http://www.gameproducer.net/?p=4802#comment-141166 re: no indenting: Agreed. magic numbers = inline constants re: no indenting: Agreed.
magic numbers = inline constants

]]> By: Juuso http://www.gameproducer.net/2010/07/04/13-easy-ways-for-making-your-very-own-collection-of-bugs/comment-page-1/#comment-141165 Juuso Mon, 05 Jul 2010 10:59:19 +0000 http://www.gameproducer.net/?p=4802#comment-141165 Magic numbers? Regarding that 4th point of yours: at least it's much better than 500 lines long functions *without* indenting :) Magic numbers?

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

]]> By: Jake Birkett http://www.gameproducer.net/2010/07/04/13-easy-ways-for-making-your-very-own-collection-of-bugs/comment-page-1/#comment-141163 Jake Birkett Mon, 05 Jul 2010 02:19:15 +0000 http://www.gameproducer.net/?p=4802#comment-141163 - 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. - 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.

]]> By: Joe http://www.gameproducer.net/2010/07/04/13-easy-ways-for-making-your-very-own-collection-of-bugs/comment-page-1/#comment-141162 Joe Sun, 04 Jul 2010 22:36:52 +0000 http://www.gameproducer.net/?p=4802#comment-141162 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. 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.

]]> By: Juuso http://www.gameproducer.net/2010/07/04/13-easy-ways-for-making-your-very-own-collection-of-bugs/comment-page-1/#comment-141160 Juuso Sun, 04 Jul 2010 19:32:04 +0000 http://www.gameproducer.net/?p=4802#comment-141160 @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..) @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..)

]]> By: Fili http://www.gameproducer.net/2010/07/04/13-easy-ways-for-making-your-very-own-collection-of-bugs/comment-page-1/#comment-141159 Fili Sun, 04 Jul 2010 19:06:36 +0000 http://www.gameproducer.net/?p=4802#comment-141159 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? 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?

]]> By: MC http://www.gameproducer.net/2010/07/04/13-easy-ways-for-making-your-very-own-collection-of-bugs/comment-page-1/#comment-141158 MC Sun, 04 Jul 2010 18:52:03 +0000 http://www.gameproducer.net/?p=4802#comment-141158 Nice post. i'm guilty of some of those points Nice post. i’m guilty of some of those points

]]> By: Pathogen David http://www.gameproducer.net/2010/07/04/13-easy-ways-for-making-your-very-own-collection-of-bugs/comment-page-1/#comment-141156 Pathogen David Sun, 04 Jul 2010 17:40:14 +0000 http://www.gameproducer.net/?p=4802#comment-141156 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!) 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!)

]]>