49

如何写出不太坏的代码

 5 years ago
source link: http://szuwest.github.io/ru-he-xie-chu-bu-tai-pi-de-dai-ma.html?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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开发


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK