如何写出不太坏的代码
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开发