如何写出不太坏的代码

2019-02-28

如何写出不太坏的代码

本来想把标题定为“如何写出好代码”的,但是转念一想,觉得自己没那么牛逼,就改成了不太坏的代码。只要不要写出太糟糕的代码,不就是好代码了吗?

以下只是个人的一些总结,如有异议,请出门右转。

1.注重命名

包括文件名,变量名,方法名。一般变量名以功能来命名,看它的名字就能知道它的用途是什么 遵循一些命名规范。Java中成员变量名一般以m开头,而OC中的成员变量一般以_开头

2.遵循低耦合,高内聚的原则编写代码

具体表现遵循分层分模块原则,底层模块不能依赖上层模块,逻辑层不依赖界面,绝不要把逻辑层代码和界面代码混在一起

3.针对接口编程,而不是实现编程

当一个类要暴露一些方法给外部调用或者通信时,先定义好接口。接口定义应该简单明了,不容易引起歧义,接口尽量少。最后才考虑内部实现,而且尽量不暴露给外部,尽量不需要外部知道内部是如何实现的

4.一个类的代码量尽量不要太大,一个方法只做一件事情

一个类(或者一个方法)的代码越多,出错的概率越大。一个类三到5百行代码最佳。如果一个类的代码太多,就要考虑这个类是不是做的东西太多了,可以拆分一下。当然,有些类(例如一些SDK基类)无法避免太大,就要好好遵循第5条准则。而一个方法也不要做太多东西,只做一件事情就可以。

5.类的方法和变量的排布应该遵循一定规则

例如:

  • 相同功能的方法尽量放在一起。
  • 生命周期方法应该尽量放一起,按时序排列
  • 公开方法排在前面,私有方法排在后面
  • OC可以充分使用category特性,同一类的方法放一起(swift的Extension也一样)

6.尽量不重复写代码,特别是逻辑代码

  • 重复代码难维护,出现bug要每个重复地方都去修改,容易漏掉。
  • 加入一个项目,在实现某个功能之前,可以先看看项目里有没有已经实现过这个功能的代码。没有必要重复造轮子。如果有,但是写得不好,或者有bug,可以跟原作者沟通让其改进,或者自己改进。除非不得已,不要重复实现。如果人人一不爽就自己弄一套,那久而久之都是重复代码,难以维护。如果相互改进,则大家一起进步。
  • 不过呢,如果一部分的代码重复可以为架构带来好处,方便维护,那是可以的,值得的。例如代码的重复可以减少两个模块之前的通信和关联,那是可以的。

7.经常局部重构

没有人能一下子就写出很好的代码,经常重构可以减少程序bug,也可以提升自己的代码质量

书籍推荐

这里推荐一本书籍,专门讲重构的,有专门讲如何对变量命名的,是一本好书。《重构,改善既有代码的质量》

Category: 技术 Tagged: iOS开发 Android开发

Comments