[iOS 知识总结一] 关于代码规范

前言

关于代码规范这个话题就比较广泛，没有绝对的对与错，只有相对的好与坏。

每个人都有自己的编码习惯，但是考虑到团队开发、项目后期的维护性上面，我觉得还是很有必要定一个代码规范的，不然项目越到后期越难维护

正文

为什么团队开发总是要扯到代码规范、Code Review 上面呢，因为每个开发者经验不同，经历的环境不同，所养成的编码习惯自然也不相同

现在基本上项目都由多人协作开发的，而且随着人员的流动，一个项目代码可能经由几个开发者之手，这个时候，如果没有代码规范，这个项目代码维护性、阅读性这些方面就会比较堪忧了

对于代码并没有什么对与错之分，只要完成了项目的功能，你是用什么方式完成的并不是很重要。毕竟软件是给用户使用的，用户并不会关心你的软件底层实现逻辑，只要能帮忙解决用户遇到的问题就好了。但是代码却有鲁棒性、松耦合/紧耦合这些区别，所以代码分好代码、坏代码 = =

好了 不扯这些虚的了，讲一下关于iOS 项目工程中的一些规范问题吧

工程中的文件层次

1. 首先全部要用真实目录，不然表面上层级很分明，其实还是乱的一团
2. 对于项目文件夹用业务模块来区分，因为是团队模块开发，这样子可以缩小问题域；对于模块的复用迁移也是很方便的
3. 合理的目录分层，尽量多去做分层，把文件安排在应该在的地方，这样子对于管理也是比较方便的，比如弄个ThirdComponents 专门来管理第三方框架的，这样子就很清楚的可以知道这个工程到底用到了什么第三方框架，便于升级和管理
4. 把Resources 文件夹打散，下落到每个模块文件夹中，这样子在模块的迁移的时候不会遗漏资源文件，而且对于每个模块资源大小也可以控制，可以检测到到底是哪个业务模块将包大小搞大了
5. 尽量不要创建Common、Core 这些文件夹，因为这样子会导致很多工具类在里面，没人维护，宁愿抽出来做组件都好

开发中的规范

1. 统一命名规范

   命名尽量采用英文名称

   名称一定要反映真实的功能含义

2. Controller控制器的命名

   采用驼峰命名法，首字母大写，Controller结尾

   例如: PXYTradeViewController

3. Util工具类的命名

   采用驼峰命名法，首字母大写，Helper结尾

   例如：PXYStringHelper

4. View界面类的命名

   采用驼峰命名法，首字母大写，View结尾

   例如：PXYTradeView

5. Plugin插件类的命名

   采用驼峰命名法，PXYPlugin开始，6位功能号结尾

   例如：PXYPlugin100001

6. Delegate协议接口类的命名

   采用驼峰命名法，首字母大写，Delegate结尾

   例如：PXYServerDelegate

7. Service业务服务类的命名

   采用驼峰命名法，首字母大写，Service结尾

   例如：PXYTradeService

8. 注释规范

   复杂的函数需要写注释，但是那些对于通用的函数就不用写注释了，反而会污染代码，注释的话统一用系统的快捷键来创建

9. 代码中尽量不要有冗余的代码，当时调试时候注释的代码，之后需要把不用的注释代码删除，文件中尽量删除没用的变量和函数，多余的换行

10. 在头文件中说明下这个类的作用

11. 打印日志的时候 禁止使用NSLog 要使用自定义的Log，避免Log 上生产

12. 代码里面禁止使用 #if 0 #elif 1 #endif 之类的 难以阅读调试

13. 发通知的Name，缓存的Key 要用宏或者静态变量，不要直接使用字符串

14. 不要有无谓的空格 换行之类的

最后

其实这种代码规范上网一搜一大把，这里就简单列举我遇到的问题，需要详细的上网搜一下就好了。规范定下来了，接下来就是执行了，一开始可能会不太习惯，但是坚持了一段时间，就会感觉还好了。