编程时常犯的几个错误、应注意的事项以及技巧

痛定思痛。 2022-09-23 14:50 32阅读 0赞

编程时常犯的几个错误以及应注意的事项：

1、忘了给变量赋初值；

2、指针出问题了；

3、对跳出循环的条件考虑不周；

4、用算法描述自己的构想时出现偏差，即描述不严密，不准确。

5、按钮点击时发生的响应处理不当；

6、数据读写时常犯的错误：未建立就读，或读写数据时格式混乱；

7、图形界面的引用发生丢失；

8、反映程序状态的值未及时更新；

9、没有恰当地使程序模块化；

10、线程控制出错；

11、响应器添加不当;

12、for循环后面加了分号作为结束，但是写着写着自己又忘了，然后自己还添上了 \{……\}，于是运行错误，想了半天，结果才发现……

13、除数为0；

14、rand、srand使用不当；

15、忘了除法运算在被除数与除数均为整数的情况下会自动取整；

16、不知道为什么，最近把i++直接放到二维数组元素中，如compAndExch\[i++\]\[0\]，compAndExch\[i++\]\[1\]，一连使用了N个这个，结果输出的数据老是不对，最后只好把i++取出来了；

17、用typedef 与struct 来定义时，忘记在结尾加分号；

18、使用\#define 时，对FALSE的定义不妥，如定义为-1，但是后面又用 !FALSE 进行判断，显然此处应定义FALSE为0，或不改，但后面用 result == FALSE 进行判断；

19、在抄写代码时，没留意是%d还是%c，导致在调试程序时因输入数据的格式错误而得到错误结果；

20、喜欢使用复制粘贴，结果把 == 也复制下来当 = 用了，编译链接时是可以通过的噢！

21、要学会分段处理，预处理、中间过程伴随处理、结尾处理；

22、善用\#define 将一些常用来判断的量符号化，如符号化为TRUE、FALSE、STATUS、UDN、DN、BOLLEAN、END等；

23、设计算法时要考虑各种极端情况；

24、设计链表时永远要记得初始化，程序出现死循环经常是因为尾指针的值未及时更新；

25、结构体定义后要加分号，而且定义出来的是变量类型、而非指针类型，千万别弄错；

26、改变的是编号，还是值呢？

27、不要试图用少许的变量去传达太多的信息，那样只会让本来可以简单的问题复杂化，多设几个标志数组，OK？

28、全面赋初值后，部分改其值；

29、“输入，判断，分支执行程序，若输入错，回到开头重新输入”，对于这种程序结构，因为用到了输入与循环，所以请用字符变量来接受，不要用数字变量，否则会进入死循环（即对%d输入字符，试一下就知道了）。

30、分支，殊途同归？殊途异归？程序结构，鼠头，蛇尾，肥猪肚？孔雀开屏？还是万流归川？

31、使用链表时，往往需要在尾部或其它地方插入，当需要每次都在上一次的尾部插入时，就应该注意每次都把尾部的指针记录下来，否则链表就无法延伸了，输出的结果也会出错；

32、在考虑算法时，不要忘了考虑边界情况；

33、可以将状态划分为两种：是，或否。任何一条解决问题的思路都可以沿着这种“是或否”的二元分支进行。

34、关于参数的传递，准确的做法是：在函数开始之前，先将要传入的数据初始化（也可以通过函数进行），然后再将数据传入，在函数内进行处理，另外函数参数列表内的参数是采用普通类型，还是引用类型，也是要经过准确考虑的。还要记住一点：数据在哪里初始化的，其作用域就局限于何处。

35、编译系统里提示的warning还是要看的。有时候一些疏忽，比如在if语句里不慎将“==”写成“=”，编译器不会报错，但在waring里却会有提示。

36、typedef一定要加“;”来结束，\#define则不使用。

\#define 替换的是字符串。typedef主要用于类型定义。

37、 在 C++中NULL已定义，而null未定义。

38、C语言里如果要考虑 程序的模块组织 时，即模块间要通信时，往往需要使用extern（用以定义外部变量）。这一点与汇编语言很是相似。各模块通过对外部变量的修改，达到传递信息的目的。

39、包含文件（.h）的用法注意点：

1、要在工程界面下新建一个C/C++ header file;

2、要区分< >（只在 包含文件目录 中查找，该目录是由用户在设置环境时设置的）与" "（现在当前的源文件目录里查找，若找不到，才到 包含文件目录 中查找）的不同。由于.h文件(比如叫做header.h)是与源文件在同一个目录下的，所以在主模块中要使用 \#include "header.h";

3、我在使用时，发现好像 \#include "header.h" 必须放在\#include<stdio.h>后才能使用。暂时还不清楚原因。

采用这种编写自己头文件的手段对较大程序的处理十分有用，既可以节省程序员的时间，还可以减少错误。

40、在编程时，如果要考虑使用信号量PV操作，我们有时候可以把它视为“上锁”、“解锁”，这样可以帮助自己理解程序的含义。我们经常使用信号量操作来实现进程互斥，当进程种类较多时，相互之间有些是互斥的，有些则不是，这样在使用PV操作时就要格外小心了，只要稍微考虑欠佳，都会造成错误结果而达不到进程互斥的目的。有些常见过程是需要互斥的，比如：进程个数的计数、读写同一对象、写写同一对象等。一旦忘记这几点，都会造成很严重的后果。

41、对于一些复杂的问题，有时候其描述语句可能很短，但是如果要用计算机算法来表达，都会显得很麻烦，你会觉得要考虑的问题比原来的问题又多了许多，感觉像是问题变大了。更不用说使用伪代码、源代码时的不便了，问题很显然，又变大了。特别是用PV操作来解决进程同步与互斥问题时，你会发现如果不仔细解析问题的描述，就会出现许多错误，但是如果仔细解析，问题就会正如刚才所言，变大了。

如何解决这个问题呢？

我们都知道，我们试图通过某些途径找到与“问题空间”响应的“解空间”，而在“问题空间”基本不变的情况下，我们无非有两种方法简化“解空间”，一、采用高级语言，这相当于使用“捷径”（因为它的代码会比较短），二、将“解空间”分解成若干部分，这样在一定程度上也能使“解空间”变小。

上述方法能让“解空间”变得“贴近现实问题”。

当然，如果上述方法如果不太奏效，我们就只能通过将“问题空间”变详细的方法，让它“贴近机器”。

其实上面所说的不外乎一个双向转化问题，具体如何转化要视具体情况而定。

42、说说文章的分类吧！当初开博客写文章时，根本没想过会写那么多，所以一开始的分类也很是简单，只有几个，后来慢慢增加了。可是有一个很严重的问题，那就是我对“学习与工作日志”没有进行更进一步的分类，随着我所学的内容的增加，有关不同方面知识的文章都被放到了里面，导致其成为一个大杂烩，很是混乱，以后要查找相应内容也很不方便，于是我今晚花了很长时间才把它们分类好，现在想来，当初真的很失策，没有一点反思，没有一点深谋远虑。

众所周知，当很多不同范畴的元素混杂在一起时，随着数量增多，处理起来就会越发麻烦，只有将它们分类好，才能方便管理。而且说不定，日后还会进行更加细致的分类，到时候才来做的话就太晚了。就算要将小类合并成大类，依旧是相对轻松的事情（相较将许多元素从中选出放入大类而言）。

这一点放到编程上也是如此，如果平常不把项目分好类，等到将来再弄就太迟了。

合理的分类，是可以提高效率的。分类，可以按语言分，也可以按科目分，按项目分，更可以按日期分。好好分类吧！要不迟早会后悔的。

43、有时候思维跳跃的比较快，在出现问题并做检查时，往往浏览得也很快，看的那一瞬间可能心里已经默认了那几句话是对的了，可是真正出错的地方，往往就在你自认为万无一失，不会出错的地方。一句一句，认真的看，才能发现错误。

44、在for循环中使用尾下标，或者从更大范围来说，在有使用尾下标的任何地方，如果需要判断，一定要想好是用<=还是用<。

45、当递归有多个出口时，要注意return出现的位置与其数目！

46、函数声明、定义、调用这几处须时刻记得保持参数列表一致，往往是改一处就要连续改好几处。

暂时想到这么多，其它的以后想到再补。

收藏于 2008-12-04