今天看到CSDN举办了“博文大赛”，觉得不错，思考了下，其中有一点很有道理：好程序员不一定能写出好博文，但能写出好博文的一定是好程序员；因为我觉得我一直没有能把文字表达清楚，我在我的博文里也提到过，当然了，我并不是一个很好的程序员，但我一直努力着改变自己，只求每天会更好一点。
好了，不多说多余的了。我想了想，选择的主题是程序模块会的见解——主要是对近期发表的程序模块会的见解总结下，和各位博友一起分享下自己的一些见解和思想。不在乎结果，只在乎能表达清晰。
总的来说，我要陈述的是关于程序模块化的四个点：
1：模块化必要性及意义
2：模块化的几个细节
3：模块化的注释
4：模块化的移植性
一：模块化必要性及意义
在很多时候，程序在没有理清思路的时候，我总是想到那里就写到那里，这里需要一个功能，就在这里添加一个功能，那里需要一个功能，我就在那里添加一个功能。完全没有模块会的概念。到最后，程序修改起来很麻烦了，尽管程序是自己写的，不仅要话费很多时间去理清思路，还得花费很多脑力去完成。
举个例子说，一个功能显示：LED显示，之前已经写好了LED显示对应的是档位显示。现在需要增加一个功能，自检功能，功能是生产时候自检灯的好坏。这时，这个自检功能是添加到哪里呢？先前我会直接在显示LED的程序里写这个自检模式，结果即使不影响之前的显示效果，显示LED的程序看起来也多了很多东西，最麻烦的是下次更改的时候，看起头很大。因此，我觉得最好的方法是，将自检模式独立写一个模块，而且，这个模块几乎不用去动之前驱动LED显示的程序。至此，增加自检的模块几乎完美的添加进入了，而且以后要更改，也相对容易。
所以说，模块化很重要，写好模块既能保持原来程序的完整性，还能提高工作效率。
二：模块化的几个细节
1：致命的标志位 ——我们也许总喜欢增加一个标志位来达到修改程序的目的。然而，这往往就会存在BUG。或许会是致命的隐形BUG,所以，按我的经验来说，我建议专门写这样一个函数，我叫他ClearFlag,在这个函数，每次我增加一个标志位如F_ONOFF，我都在函数ClearFlag中写入(F_ONOFF
= 0;) ，这样我们就不怕新增加的标志位了。
2：新增加模块尽量使用static 的变量，这样，下次我们看到这个模块，一下子就知道只用在这里，不用思考其他的了。
3：写新的模块时，可以将已经理解好的功能宏定义在H文件中，方便下次需要时用。比如一个芯片的定时器TIM1有1分频，2分频，4分频等等，控制位2位，第3位开始，这时我们就 宏定义#define TIM1_DIV1 （0<<3）#define TIM1_DIV2 （1<<3）
4:多使用#if defined() #endif。在我们的程序模块功能越来越多的时候，有些模块是不用的，而有些编译器不会自动优化，这时我们只要将下面#define TraWork 前面增加//就可以注释了，此模块程序也不会占用Flash了，模块我们也可用保留在程序中，想要用的时候去掉//就可以调用了
#define TraWork
#if defined(TraWork)
//程序内容
#endif
三：模块会的注释
写好一个好的程序不容易，修改好一个好程序更难。 调试程序中，往往会遇到这样的情况，需要增加修改一个程序，这时聪明的程序员更改了程序，好，测试也OK，就这样，把程序给封存了。这里，很多人都会犯了一个错误，就是注释的问题，我们发现，再过10天半个月，又来更改程序了，我们的第一感觉就是反感，呵呵，因为你可能要得重新理解一次，也就是我们不喜欢重复的感觉。但如果你之前已经完全有注释和提示功能更改的方向，就会增加自己的信心，也许也不会第一时间反感。为此，我认为，注释也是程序的重要部分，甚至比写好程序重要，并且可能花的时间要比修改程序的时间还要长，自己有时间最好，没有时间要挤出时间，把这事当作必要之事，同时，注释过程，理清思路，发现BUG,总之，做好注释，一辈子都不怕一再修改程序。
四：模块化的移植性
通过一个实例来描述，函数功能很简单：扫描LED LED的显示有不亮、闪烁、常亮 3种方式，其中闪烁次数是有规定的，我的是3次（具体是 闪烁3次，周期是0.5秒，即亮0.25秒 灭0.25秒）
F_FlsLock = 1;//启动时闪烁3次
F_FlsLock =0; F_LockEn =0;//LED不亮
F_FlsLock = 0; F_LockEn =1;//LED常亮
这是我第一次写的程序，5毫秒扫描一次。
void LedLock(void)
{
static uint8 TimeFlash = 0;//闪烁时间
static uint8 FlashTimes = 0;//闪烁次数
if(F_FlsLock)
{
if(++TimeFlash <= 50)
{
P_LED = 1;
}
else if(++TimeFlash <= (100-1))
{
P_LED = 0;
}
else
{
TimeFlash = 0;
if(++FlashTimes >= 3)
{
FlashTimes = 0;
F_FlsLock = 0;
}
}
}
else
{
if(F_LockEn)
{
P_LED = 1;
}
else
{
P_LED = 0;
}
}
}
这是我第二次写的程序，5毫秒扫描一次
void LedLock(void)
{
static uint8 TimeFlash = 0;//闪烁时间
static uint8 FlashTimes = 0;//闪烁次数
if(F_FlsLock)
{//需要闪烁
if(++TimeFlash <= 50)
{
F_LedLockEn = 0;
}
else if(++TimeFlash <= (100-1))
{
F_LedLockEn = 1;
}
else
{
TimeFlash = 0;
if(++FlashTimes >= 3)
{
FlashTimes = 0;
F_FlsLock = 0;
}
}
}
else
{
F_LedLockEn = F_LockEn;
}
}
//
if(F_LedLockEn)
{
P_LED = 1;
}
else
{
P_LED = 0;
}
表面可以看出，第2次的程序比第一次多了I个标志位F_LedLockEn 。更深一点：如果这两个程序的移植性是那个好呢？这就是我主要说的，如果这两个程序都用在一个相同的驱动电路，即VDD-LED-电阻-GND,那么就没有什么区别。但如果用在复用，即按键和LED共用一个IO或者LED共用COM,这时功能相同，LED驱动更改肯定要的，但判断是否显示和闪烁是时间和次数可以不改，对此，如果是第一个程序，那得大改了，哈哈，那又得浪费时间和脑力了，但第二个程序，可以应用多种电路接线方式，只需要更改LED驱动方式，再通过F_LedLockEn来确定是否亮与不亮即可。这里可以看出，判断LED是否亮的模块和LED驱动模块完全区分开，这样，两个模块就可以单独移植和修改却不相互影响。我们不是要做到这样的吗？
我说得可能还是有些欠缺，但总之，程序的模块化要做到，即使我们到了100岁，我也不怕修改，也能很容易移植，这才是程序模块化灵魂所在。
至此，我的表达已经结束，谢谢。
程序模块化的阶段性总结