编程心得

 

需要注意以下几个地方：

1.       系统资源：

a)         需要注意程序占用CPU的时间：对于长期运行的程序来说，稳定性比运行速度更重要，没有必要占用满负荷的CPU，所以，程序中应该考虑增加延时(sleep)。防止程序自身占用过多CPU。举例：比如历史数据续传问题，当主机开始读取历史数据文件时，如果不增加延时，就会占用大量CPU，影响正常调度主机的运行。

b)        内存占用，小数据量不会有任何问题，但是对于设计考虑不足的方案就有可能出现内存占用过度的情况。

c)        IO瓶颈，数据库操作、文件操作肯定没有机器本身的内存操作速度快，所以，应尽可能少的进行IO操作，从而均衡程序的性能。

2.       文件处理：

a)         注意系统空间：如果系统空间被沾满，很有可能会引起系统方面的故障，这样的程序是不适合长期运行的。比如历史数据上传的问题，在方案中需要将历史数据记录成文件，显然，该数据是非常大的，如果不断记录新数据而不考虑空间问题，就会对系统运行造成影响。

b)        注意文件处理是需要过程的：例如，在历史数据续传问题的处理中，原设计只要主机发现文件夹下存在相应文件，就开始读取数据，后来发现，大文件传输需要时间，很有可能在文件的读取过程中，文件仍然在传输。因此，需要在文件传输完成后，进行握手，或者使用文件标识，才能进行读取操作。

3.       数据类型：

不同的数据类型其占用存储的大小是不同的，曾经在做程序的时候遇到循环的次数怎么都不对，一检查才发现是循环的边界条件赋值时溢出了，应该是xxxxxxxx的，结果接受值的是一个int，数据太大，放不下，就造成了上面的问题。

 

4.       跨平台移植：

    1）字节序：

    不同的机器其高低字节顺序不一样，在读写文件或，网络传输时容易造成问题。

2）移植性：

    最近负责一个程序的应用移植，应该说应用的需求是类似的，不同的只不过应用中所使用的某些名称不一样，数据排列不一样而已。但是在移植的时候就发现，程序中到处是写死了的名字和魔数，而且这些东西也没有通过宏定义或者其他方式集中写在文件头或者尾，而是东一块西一块，写在函数使用的地方。说实在的，遇到这样的情况，心里就开始发毛，生怕有漏改的地方，能马上发现也好，倘若不能及时发现，那日后就成了隐患。指不定哪天捅出点篓子，吃不了兜着走。所以，提醒自己一下，自个写程序的时候也得为后来人考虑考虑移植性的问题。

 3）注意函数库的不一样（string.h 和strings.h）；

 4) 32位机器：能够编译32位代码，执行32位代码；

    64位机器：能够编译32或者64位代码，能够执行32、64位代码，不过，默认生成32位代码，如果指定生成64位，在solaris上需要增加编译开关-xarch=generic64;

 

5.       空指针：

许多地方指针都会产生core，直接造成程序不能继续运行。会被空指针影响的函数：strcmp、strcpy等；

容易产生空指针的函数：strtok。

 

6. 共享变量：

   某程序，本人写成如下代码：

    time_t t1, t2;

    struct tm *tm1,*tm2;

    t1 = xxx;

    t2 = xxx;

    tm1 = localtime(&t1);

    tm2 = localtime(&t2);

    下面对tm1与tm2进行操作，惊奇的发现居然tm1与tm2中的时间都是一样的。这根本不可能，后来才想到，为嘛tm1为指针，那相应的地址从哪来呢。。。估计是系统里面有一个公用的内存块，所有的tm结构都指向了这个内存块。这就教育我自己，在使用一个结构或者变量时，得时刻提醒自己注意这个数据是不是共享数据。

 

7.  运行性能：

     运行性能无非两个方面：1）循环太多;2)循环里面语句复杂;不过具体查问题的方法还是比较原始，至少我只知道用gettimeofday来取毫秒，再通过printf的方式进行二分。

     最近完成了一个数据库相关的功能，这个功能完成后，发现运行效率不高，一次查询时间很长，到了用户没有办法等的程度。花了n久发现，memset的时间非常长，原因是相应的设值内存块比较大。提醒自己注意，memset也是需要时间的。

 

8.  提高自己的编程速度：

    a.熟悉函数API；

    b.建立自己的功能函数库，不要做完一个代码就丢掉；

    c.practise；

 

9.  数据库操作：

    1）不能在单位时间里面进行过多sql操作；

      在mysql上进行测试，发现如果在单位秒里面进行了过多的sql操作， mysql进程会占用大量的CPU资源；解决方法是，将sql语句合并，比如把多个单行的insert语句合并为一个insert into xxx  value （）， （）， （）；

    2）数据库单表记录数不能过多：

      在mysql上进行测试，当超过6w条记录后，相同sql语句的操作所占用的cpu资源会增加。

 

编程习惯：

1. 重复代码：

   最近在负责一个程序的维护，程序里面对一个sql查询功能分几种情况分别写了函数。其实，这几个函数里面除了个别参数不一样，查询表不一样以外，完全相同。但对这几个函数做相同的功能增加时，就感觉到了痛苦，几乎相同的代码，要我改上n遍。一个可能很简单的程序，就这么变成了千余行。看起来都费劲。所以，提醒自己切记，写代码的时候，尽量的将冗余代码合并，方便维护，表出现我面前的这种代码，被后人骂。。。

 

这里付csdn上看到的一个帖子，说的是关于编程习惯的几个观点，作者语风很犀利，貌似受到很大的刺激：

 

0，你写的代码是要给别人看的，算我求你了，一定要有点编程规范，一定要做必要的注释。

1,TAB键让你用的很顺手吗？我只是想告诉你，当你的代码换个环境看的时候，会很难看很难看而已，完全不是你想表现的那个样子了。
2，拜托像int a；中间那个空间千万不要先一个空格再一个TAB。window下怎么样我不知道，不过在linux下从千万的代码中找到你这个名字可就真难了，grep的条件不用上复杂的正则表达式是什么也找不到的。

3，我也知道//的注释用起来爽，用起来方便。只是你用起来方便，别人看起来就不方便了，感觉哪里都像一坨屎一样。linux下的编辑器还是习惯了/**/。

4，空行只是占用代码的空间，对编译之后的size完全没影响，一段功能的代码之后随手敲个回车不是个什么大事吧!

5, 我也知道调试代码很郁闷的，不过即使很累了还是要请您整理下代码，毕竟谁也不想自己的代码被人骂成狗屎样吧！

6，现在部署一个版本控制也不是个什么难事，历史的代码就不要占用未来的空间了。