(提问前先看)如何调试程序与提问 V0.1

最新推荐文章于 2024-10-03 00:19:28 发布

liujinkong

最新推荐文章于 2024-10-03 00:19:28 发布

阅读量418

点赞数

分类专栏：编程入门文章标签：调试提问 debug

本文链接：https://blog.csdn.net/liujinkong/article/details/102094811

版权

编程入门专栏收录该内容

2 篇文章 0 订阅

订阅专栏

本文作于当C++助教之时，主要目的是希望当同学们在遇到问题时，可以有依据地思考和debug，在此基础上再请教别人。毕竟debug能力也是程序员的必备技能

编译未通过

一般是语法问题，比如错打分号，少个空格，敲错变量名，头文件名，main函数名等等。Visual Studio会给出错误提示，甚至是错误所在行号，仔细观察即可发现问题。如果问题比较奇怪，可以复制错误号问度娘，看看能不能得到相应的提示。
如果Visual Studio没问题，而oj不通过，很可能是复制过程出错。

没有得到预期的输出

1、断点调试法
跟踪程序执行过程，目前课上还没教到，有兴趣的同学可以先看一下网上的资源。比如：
百度经验：如何用vs2012对C语言进行调试
 如何使用VS2012进行简单程序的DEBUG（入门级）
如果掌握了这个方法，可以找到几乎所有的入门级逻辑问题。

2、打印输出法
vs中，在main函数return之前，可使用system("pause")查看控制台输出，如果与预期不符，那一定是程序中某处出了逻辑问题。如果和预期一样，很可能是ascii码不一致的问题。
如果一时找不到，而且也不会使用断点调试法，那么可以采用一种比较原始的debug方式：打印中间过程变量，尤其是循环中的变量。这是工程上常用的方法之一：打调试日志。如果实在找不到问题，截图请教别人时，也希望同学们能采用这个办法，更方便他人定位问题。 下面举一个例子。

//要求：输入一个正整数，输出不大于该数，且是17的倍数的所有正整数
//输出用空格分割，结束时换行
#include <iostream>
using namespace std;
int main() {
    int a, i;
    cin >> a;
    for(i = 1; i <= a; i++)
    {
        if(i % 17 == 0){
            cout << i ;
            if(a - i > 17)
            cout <<' ';
        }
    }
    cout << endl;
    return 0;
}

这个程序看似把问题都考虑到了，但测试时却发现经常没有输出，如果肉眼看不出问题，就可以在循环中打印各表达式的值，观察运行结果，如下所示：

//要求：输入一个正整数，输出不大于该数，且是17的倍数的所有正整数
//输出用空格分割，结束时换行
#include <iostream>
using namespace std;
int main() {
    int a, i;
    cin >> a;
    for(i = 1; i <= a; i++);
    {
    	//加入这一行，打印循环中各关键表达式的值
    	//有助于发现逻辑错误，以及运算符优先级等错误
    	cout<<"debug: i = "<<i<<"  "<<"i % 17="<<i % 17<<endl;
        if(i % 17 == 0){
            cout << i ;
            if(a - i > 17)
            cout <<' ';
        }
    }
    cout << endl;
    return 0;
}

哎，debug怎么只打印了一次？是循环只运行了一次吗？哦，是for循环多打了一个分号，把它去掉就好了。当然，oj提交前别忘了把调试输出注释掉。
如果程序比较简单，顺序执行，没有循环，那么学习一下单步调试，这样更方便一些。
所以，如果运算结果与预期不符，建议同学们一定要先在循环中打印相关的表达式，如果仍然不能解决，再将表达式以及中间运算结果一并截图，到群里向别人提问。

3、求助他人
如果1、2都不能解决，那么可以考虑求助大神。但正确的提问也是一种艺术，非常不建议直接丢出一坨代码，说“求问大神，我哪儿出错了”。为了能尽快获得答案，你需要尽可能多的提供有效信息，比如说步骤2所给出的中间变量，以及程序的正常运行结果。当然，良好的变量命名，正确的排版（比如缩进），以及关键语句的注释都会增强程序可读性，给人良好的印象。尤其是注释，写注释时候相当于自己重新梳理一遍程序的工作流程，很可能在写注释的时候，就找到了问题。