/********************************************************************

* Filename:一线研发之声：嵌入式C编程经验 之 请写可移植性高的模块

* Author：SedateFire                        E-mail:SedateFire@126.com

* Version：1.000                                Time: 2012-01-05

* key: 嵌入式 可移植性 模块化 依赖

********************************************************************/

我想你或许有这样的经验，你要实现的一个模块同事已经实现了。老板发话说：你复用他的代码啊，半天给我搞定。于是你拷过来编译一下，几乎是必然的，会有error有warning，一看，哇，原来依赖了这么多外部的东东。于是你开始着手修改它，如果模块小，自然三两下搞定。如果是个大的模块要复用，一下弹出几百个编译错误报警，我想你边修改心里也边骂娘。

我靠，这个蜂鸣器控制函数为何要去判断当前在作什么应用？！

我靠，这么多缺失的include文件，没有拷过来吗？

我靠，这个函数是什么东东，注释明显对不上，还判断赋值了一堆全局变量。

我靠，这个if处理了，那else呢，哪里去了？这是什么跟什么啊。

我靠，通通删掉干掉，自己加班偷偷重写好了。

什么！老板在催了，我靠靠靠啊…

想必你有共鸣了......

那么如何实现可移植性高的代码呢，我就先写几点吧，有些晚了，准备睡觉了

1.擅用define。请把“裸露”的常量，用短小又信息准确的宏定义起来，务必全大写。常量的宏定义要大写，我会在后期关于代码规范的主题文章分析。请把设备驱动的io，用define定义分离出来。当然，还有许多妙用，宏定义简直是移植旅行必备佳品。待我后期再整理下思路吧。

2.抽像出平台依赖严重的代码。比如访问一个特定mcu寄存器，开关中断，清狗指令，中断写法等等。

3.如果可以，我希望你的.c档中包含的.h档尽可能的少。这样在移植的时候，你只要看包含了那些.h档，你就知道该模块大概依赖了其他哪些模块。我知道，大多数的程序员都喜欢在.c档的文件头仅有一个

＃i nclude "includes.h"

而在includes.h 中包罗万象，这是原罪！当然，要一个萝卜一个坑地梳理清楚.c与.h档的关系，需要长期的工作经验，尤其在编译条件错综复杂时，操作起来的确痛苦且容易出错，但其实这已经预示了你系统架构的某种不合理。

如果没有足够的经验，那么我建议你，先在设备层的.c档尽量包含尽可能少的.h档。然后把设备层的.h档放在includes.h中，给应用层使用。

3. 打造自定义库，这个准备设专题讲解。

4. 通信数据统一是大端的，内部应用代码统一用数值说话，和大小端无关，不要乱糟糟的一片胡写蛮缠。少用union，发送数据时统一用单字节移位发出去，接收时用移位收进来。牺牲了效率，但提高了可移植性。在51中也许不大现实，但在未来M3的大趋势下，效率是可以牺牲的。

5.欲知后事如何，请听下回分解....