如何写出不太坏的代码

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

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

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

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

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

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

例如：

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

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

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