我们程序员通常将自己所犯的错误称作“漏洞”。承认犯错非易事，但承认作品存在漏洞要简单得多。

game bug from thatvideogameblog.com

出现下述13中情况，作品将很容易出现漏洞：

1. 未利用功能（或者对象和类）。

2. 运用大量IFs。

3. 复制 & 粘帖代码。

4. 在编码过程中坚持添加“特例，只为处理此情形”原则。

5. 编辑错误文件。

6. 做出大量调整，然后进行一次性测试（而不是每次更新调整后都测试一次）。

7. 试图同时给3-7块不同内容编码（而不是挨个编码）。

8. 调整某些编码，以进行“短暂”测试，但其后却并未通过文件说明这么做的理由。

9. 单纯依赖调试模式，未在发布模式中测试内容（游戏邦注：这会造成许多漏洞而不只是一个错误）。

10. 放置某些代码（当然没有进行存档），然后将其闲置2周。

11. 在一天将结束前着手大块内容（第二天早上就会发现情况一团糟）。

12. 在当前游戏中运用某些之前创造的代码（而后发现原先的代码错误不断）。

13. 运用简化变体名称（例如，将creditCard, i, height, heIsRockingYourBoat简写成c, cc, i, h, hiryb这类字母)。

游戏邦注：原文发布于2010年7月4日，文章叙述以当时为背景。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

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. （Source：gameproducer）