今天看到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岁，我也不怕修改，也能很容易移植，这才是程序模块化灵魂所在。

            至此，我的表达已经结束，谢谢。