怎么没有 A ?

调试，其实质是排错，与测试是两个不同的概念，后者用于发现错误（一般由编程者之外的人进行），而前者才是排除错误（是发现错误之后由编程者自己或维护人员解决的），因此调试的主要目的就是排除错误。排错是艺术技能，没有现成可学的必然手法。根据实践总结，不同的人有不同的排错能力，故此有人说这是天赋，不无道理。

不过，排错还是有一些基本方法的，总结起来，大致是如下三种：
1.蛮干法，硬追踪，主要是跟踪程序流程，监视其动作和数据变化，发现错误位置，有一定的运气，花费的力气较大；
2.原因消除法，从程序设计逻辑上分析错误的原因大概在哪里，再有针对性地通过增加数据、设置陷阱等方法定位错误；
3.回溯法，从错误处倒转查找，逐行排除，对小程序和少分支、少数据量的程序适用。

以上就是排错的基本方法，自己灵活运用，没有通法的。另外，编译信息也是很重要的调试手段，它能帮你把错误消灭在编码阶段，而不至于到运行时才出错。须知运行时才发生的错误，往往是逻辑问题了，有相当的隐藏深度，优秀的编程者都力求把错误消除在编译阶段。忠告：把编译开关设到最严格状态，不放过任何警告信息，直到编译时没有任何警告和错误；宁愿在编译时出错，也不要在运行时出错。

看看新手问的问题，绝大多数都是本可以在编译阶段检查出来的。


[ 本帖最后由 TonyDeng 于 2011-9-17 17:27 编辑 ]

只有自己做过调试，才能懂得在设计和编码的时候如何避免错误，才能懂得什么才是真正优秀的编程。那些习惯于写别人看不懂的代码的人（他以为只有别人看不懂才能求他从而不被淘汰），其实只是把调试的艰难留给自己，这样的程序越多，自己的负担越重，最后压死自己。我20年前写的程序，到现在仍在运行，从最初的两三年内有大约每季度修改维护一次之后，就再也没有问题要修改，只有这样，才能真正释放自己，去做更多的程序，否则旧程序不断压回来，新程序又起，你三头六臂也搞不定。程序是写给人看的，清晰性和简单性优先，玩技巧是没用的。优化的算法必然是更复杂的代码，也带来更困难的调试，如无必要，最好不要做，运行时没人差那几十毫秒的时间，但排错的时间绝对不止几十毫秒。

[ 本帖最后由 TonyDeng 于 2011-9-17 17:49 编辑 ]

大概是B吧

多选题吗？

举一个实际的例子：

总有人犯那些多一个分号、少一个分号之类的错误，拿出来问，人家指出了就说“以后决不要再犯”，但事实上仍会再犯（事实上再高的高手也会犯这种错误，只是他们很快就能查出来，不会公开问人），这首先是不会自己调试排错造成的，其次是不懂调试之下导致从来不懂如何养成良好的写码习惯（习惯依赖别人指出了）。其实，像for循环后面多一个分号造成错误那样的错误，只要用蛮干法跟踪一下程序的流程，就能马上发现，你会看到执行指针一直在同一行打转，而没有按预期那样执行下面的代码，此时马上就能醒悟是分号问题。这其实是不用教的“技巧”，脑瓜子灵的，都能想到，想不到就绝对是天赋问题，不适合学编程了。

那么，如何解决呢？从跟踪的过程中，我们看到指针的指向是很重要的，那么编码时就要明确让指针一次指示一个动作。写for循环，良好的“习惯指法”是先写for(;;)，然后马上写花括号，即
for(;;)
{
    ;
}
写好这个格式之后，再返回来填入具体的代码。这样，即使是空循环，也是很明显的，什么语句该写在什么地方，也不会错。培养好这个习惯，还会老犯同样的错误吗！

跟踪程序指针，也告诉我们为什么不要在一行上写多个动作，诸如(i++;j++)之类的代码，一行执行两个动作，就应该戒除，因为如果你在调试的时候，程序崩溃在这样的行上，你就搞不清楚是i++导致的还是j++导致的。这样的代码，分两行写，不会影响程序效率丝毫，但对调试却有万利而无一害，怎么不肯做？

从以上所述，就可以看到调试与编程之间的关系，那是不可分的。

[ 本帖最后由 TonyDeng 于 2011-9-17 18:19 编辑 ]

个人认为C

正确答案是什么啊？
就差A没出来了

这种题感觉祸害人，不严密

排除法  选C
就算调试通过，程序也不一定正确，有可能运行出错。  B 错
调试是不可能帮你改正错误的，调试只能帮你找到错误。  D错