怎么写可读性好的面向过程的代码？

Posted 2020-11-21 ydf0509

 最近接受老代码，mmp的，说是重新运行运行起来，那还不如重写呢，因为有很多毛病，不能直接运行，有包括语法错误问题和内存严重泄露的问题，而且很难看懂代码，修改也不方便。

 

1、笼统的说，大部分人都认为面向对象适合大项目，小项目使用面向过程好，那么这到底是为什么呢，不知道大家有没有思考和体会和实践对比过，还是对此完全没有任何心得体会只是跟风这麽认为？

 

2、python是很精简的，300行抵得上java500行。

当一个300行的面向过程的，写了十几个函数，一环套一环的return和传参，看得就会脑袋发烫了，除了自己能看懂别人是看不懂的，因为python很多人都没写参数的意义注释和类型注释（这两者缺一不可，java只需要有参数含义注释就行了，因为参数前缀已经是强制声明类型了，不需要再写类型注释），所以这种代码函数到底是干什么的，还需要跳转到调用它的地方去，频繁的跳转效率很低，尤其是完成长流程的项目，一环套一环的return和传参更是如此。

 

3、在单文件和顶层运行文件时候，写一个300行的面向过程代码，应该使用下面这种思维方式：

少return少传参，多写全局变量，因为 很多函数都操作相同的东西，写成全局变量就能很直观看到他是操作同一个东西了，如果是写成传参，并不能直观感受到。一个300行的代码，如果一直这么return和传参，我脑袋就发烫了，效率就会下降很多。因为你写的不需要被import作为基础组件，也不需要多实例，那应该尽量多用全局变量。最好是多用三方包 多用三方框架，少自己写得一坨一坨的，不然接盘侠是肯定 看不懂的，因为框架规定了你怎么写，有约定俗成的在什么文件写什么代码，接盘者不需要去看你写的思路，因为大家对框架或者三方包都有共识。

 

因为看到一个代码写了3个函数里面的传参分别叫city  item region，但其实是操作同一个东西，写作者既不写参数类型注释又不写参数意义注释，在不同函数中起的名字又各种各样，然后不能表达出参数是一个字典，city 和region意思明显是一个字符串类似 北京 上海什么的，却让它表达的是一个城市字典信息，他要表达的是{‘name‘:‘北京‘，‘id‘:123}，但用这个名字真的是日了狗，想搞清楚它必须一步一步的从函数调用处去分析它，调用不同函数的地方间隔代码行数太长，上一秒搞清楚了下一秒就忘了。所以一定要把名字起好，然后多写全局变量，例如本例中把这个城市信息字典写成全局变量，。不同函数操作的结果不需要return，需要return的直接修改全局变量，这三个函数不需要那么多次重复传参，因为函数可以直接引用全局变量。因为操作全局变量就很容易直观的看到函数到底在操作什么，如果使用函数传参，根本就不知道他要操作什么东西，必须跑到调用函数的地方去看（如果使用面向对象那就是操作实例属性了和这种方式的操作全局变量的思维差不多，但能很好地克服了既不用全局变量，也不需要频繁传参和return）。

 

 

 

5、除了上面这个方式外，就是不要使用面向过程了，要学习面向对象和23种设计模式。

在学校学习嵌入式一期时候做过五子棋，是使用c语言面向过程做的，当时写了1300多行来完成这个项目，收尾时候老师说二期后学习c++后要用面向对象会更简单，但当时并没有把五子棋作为二期的任务，而是做音乐播放器移植到arm板。

 

关于面向过程和面向对象解决五子棋的流程：

 

例如五子棋，面向过程的设计思路就是首先分析问题的步骤：

1、开始游戏，
2、黑子先走，
3、绘制画面，
4、判断输赢，
5、轮到白子，
6、绘制画面，
7、判断输赢，
8、返回步骤2，
9、输出最后结果。

   把上面每个步骤用分别的函数来实现，问题就解决了。
  
   而面向对象的设计则是从另外的思路来解决问题。整个五子棋可以分为：

1、黑白双方，这两方的行为是一模一样的，
2、棋盘系统，负责绘制画面，
3、规则系统，负责判定诸如犯规、输赢等。

   第一类对象（玩家对象）负责接受用户输入，并告知第二类对象（棋盘对象）棋子布局的变化，棋盘对象接收到了棋子的变化就要负责在屏幕上面显示出这种变化，同时利用第三类对象（规则系统）来对棋局进行判定。

   可 以明显地看出，面向对象是以功能来划分问题，而不是步骤。同样是绘制棋局，这样的行为在面向过程的设计中分散在了总多步骤中，很可能出现不同的绘制版本， 因为通常设计人员会考虑到实际情况进行各种各样的简化。而面向对象的设计中，绘图只可能在棋盘对象中出现，从而保证了绘图的统一。

   功 能上的统一保证了面向对象设计的可扩展性。比如我要加入悔棋的功能，如果要改动面向过程的设计，那么从输入到判断到显示这一连串的步骤都要改动，甚至步骤 之间的循序都要进行大规模调整。如果是面向对象的话，只用改动棋盘对象就行了，棋盘系统保存了黑白双方的棋谱，简单回溯就可以了，而显示和规则判断则不用 顾及，同时整个对对象功能的调用顺序都没有变化，改动只是局部的。

 

从中可以发现，即使你不用继承和多态，面向对象带来的优势也是很大的，可读性会提升很多，不会导致接盘侠看不懂维护不了。当然前提是接盘侠会使用面向对象了，如果不会，那么你是用面向对象编程对他来说反而是个负担了。