关于提高代码质量的思考之提高代码健壮性

    接着上期的拓展性之后，今天谈谈代码的健壮性。代码的健壮性又称鲁棒性，是高质量代码的一个重要指标。

     

      有人分析了印度软件行业比中国好的一个原因：印度的一个老程序员，月代码量在一千行左右，这一千行代码，算法平实，但都是经过仔细推敲，实战检验的代码，不会轻易崩溃的代码。我们的程序员，一天就可以写出一千行代码，写的代码简短精干，算法非常有技巧性，但往往是不安全的，不完善的。印度人的程序被称作：傻壮。但程序就得这样！

      那么如何写出一个代码简短精干，算法非常有技巧性，而又非常安全的代码呢？我逛了很多论坛，发现主要有如下几点：

      1. 内存泄漏的检测

    内存泄漏是C语言代码里面比较容易忽视而又非常难查找原因的问题。这里推荐一组C语言代码，感觉挺不错的----memwatch，将其放入我们的项目中一起编译就可以了。当我们执行编译后的程序时，就会在所在目录下生成memwatch.log日志文件，里面就是程序的内存使用情况的描述。举一栗子：（这是一段有内存泄漏的代码）

 1 #include<stdio.h>
 2 #include<stdlib.h>
 3 #include"memwatch.h"
 4 
 5 int main(int argc, char* argv[])
 6 {
 7         char*p2;
 8 
 9         p2= (char*) malloc(sizeof(char) * 128);
10 
11         return0;
12 }

执行编译命令：gcc-DMEMWATCH -DMEMWATCH_STDIO a.c memwatch.c

ps：要记得编译的时候定义宏MEMWATCH和MW_STDIO哦
执行测试程序：./a.out
查看日志文件：vim memwatch.log

输出结果如下：

=============MEMWATCH 2.71 Copyright (C) 1992-1999 Johan Lindh =============

Startedat Tue Nov 26 10:23:48 2013

Modes:__STDC__ 64-bit mwDWORD==(unsigned int)

mwROUNDALLOC==8sizeof(mwData)==56 mwDataSize==56

Stoppedat Tue Nov 26 10:23:48 2013

unfreed:<1> a.c(9), 128 bytes at 0x1fa8310 {FE FE FE FE FE FE FE FEFE FE FE FE FE FE FE FE ................}
Memoryusage statistics (global):
N)umberof allocations made: 1
L)argestmemory usage : 128
T)otalof all alloc() calls: 128
U)nfreedbytes totals : 128
MEMWATCHdetected 1 anomalies

从上面的输出可以看出，在a.c中第9行动态申请的128bytes没有释放掉，
如果正常编译的话gcca.c
调用valgrind./a.out 会显示

totalheap usage: 1 allocs, 0 frees, 128 bytes allocated

…

如果用gcc-DMEMWATCH a.c memwatch.c编译的话，再调用valgrind./a.out就会显示:

All heap blocks were freed – no leaks are possible

证明memwatch帮助我们把没有释放掉的空间释放掉了。　　

      2. 异常处理
    如果你写的代码里面有较多的输出输出，你就要考虑异常处理了。如果你需要你的代码更加的完善和健壮，完善的异常处理机制也是必要的，C语言中，有很多异常处理的方法，常用的有assert、errorno、exit等。这些百度就一堆了，我就不当一个搬运工了。有一个比较好的方式，就是自己重新定义assert函数。可以像这样：

void __assertex__(const char *file, unsigned int line, const char *function, const char *expr);

当然网上也是有很多方式的，这个也是需要根据自己的实际情况来修改这个函数的。可以参考百度哦。

      3. 引入日志

    最后，日志系统对一个健壮的系统来讲是必不可少的，这点毫无争议。当然对于一个小型系统，引入日志是一件非常有好处的事情，目前我的身边就有好多例子，由于客户修改了某些信息后出现问题，我们通过查看日志可以直接定位到用户在什么时间进行了如何的操作，能比较好的对出现的问题进行定位解决。日志也不是越复杂越好，需要根据实际情况确定自己的系统中需要怎样的日志，需要记录什么，或者说以后可能会需要哪些方面的需求。

    每天进步一点点！

 

转载于:https://www.cnblogs.com/cjiejie/p/5500059.html