iOS 开发代码规范

• 前言：
  1. 最近新接手一个项目，代码无论是从基础的代码规范还是设计模式上来说，几乎没有任何规范性可言，都是自由奔放，随心所欲的写。
  2. 为了给团队整理一份iOS代码，自己先写一个版本。

一、规范制定说明

1. 前言

(1) 为什么会有代码规范？因为我们是团队协作项目，如果是你一个人的项目，没有人在乎你的代码规范，你写的代码风格完全任凭你的心情，没有人会care。
(2) 为提高产品代码质量，指导广大软件开发人员编写出简洁、可维护、可靠、可测试、高效、可移植的代码，我在这里先提出一个代码规范版本。
(3) 代码规范没有绝对的正确性，但是风格统一性很关键，它可以帮助我们团队里的代码像一个人写的代码，会更节省维护成本。

2. 代码总体原则

a. 清晰第一

(1) 清晰性是易于维护、易于重构的程序必需具备的特征。代码首先是给人读的，好的代码应当可以像文章一样发声朗诵出来。

(2) 目前软件维护期成本占整个生命周期成本的40%~90%。根据业界经验，维护期变更代码的成本，小型系统是开发期的5倍，大型系统（100万行代码以上）可以达到100倍。业界的调查指出，开发组平均大约一半的人力用于弥补过去的错误，而不是添加新的功能来帮助公司提高竞争力

 “程序必须为阅读它的人而编写，只是顺便用于机器执行。”
——Harold Abelson 和 Gerald Jay Sussman
“编写程序应该以人为本，计算机第二。”
——Steve McConnell
1
2
3
4

(3) 一般情况下，代码的可阅读性高于性能，只有确定性能是瓶颈时，才应该主动优化。

b.简洁为美

(1) 简洁就是易于理解并且易于实现。代码越长越难以看懂，也就越容易在修改时引入错误。写的代码越多，意味着出错的地方越多，也就意味着代码的可靠性越低。因此，我们提倡大家通过编写简洁明了的代码来提升代码可靠性。

(2) 废弃的代码(没有被调用的函数和全局变量)要及时清除，重复代码应该尽可能提炼成函数。注释的代码尽量删除，除非随时要打开的部分特殊代码。

(3) 本规范通过后文中的原则（如文件应当职责单一/一个函数仅完成一件功能）、规则（重复代码应该尽可能提炼成函数/避免函数过长，新增函数不超过50行）等说明简洁的重要性。

3.规范实施、解释

(1) 本规范制定了编写iOS开发语言(Objective-C、Swift)程序的基本原则、规则和建议。

(2) 本规范适用于公司内使用iOS开发语言编码的所有软件。本规范自发布之日起生效，对以后新编写的和修改的代码应遵守本规范。

(3) 本规范由iOS团队发布和维护，code review以本规范为原则提出comment意见，实施中遇到问题，可以组内讨论。

(4) 在某些情况下需要违反本文档给出的规则时，团队必须通过一个正式的流程来评审、决策规则违反的部分，个体程序员不得违反本规范中的相关规则。

二、规范

1. 命名规范

(1) 驼峰命名
针对属性,变量,方法等均采用小写字母开头的驼峰命名准则。
例如：

@property (nonatomic, copy) NSString *codeType;
1

(2) 前缀
a. 项目名称,类名,文件名都应该保持一致的前缀名,根据 Apple Guide 建议类名前缀应该使用 2 个英文以上最好。
b. 因为 Apple 写的框架都是直接使用 2 个英文字母开头, 使用 3 个字母 能有效防止类名重复影响工程。

TODO: 未完待续

1. 头文件引入

(1) 在 .h 文件中尽量使用 @class 声明文件, 直到 .m 文件中真正需要的时候在使用 @improt 进行引用, 能有效的防止其它类引入此类时, 一并也引入了
(2) @improt 文件顺序: 可以先写引入系统文件, 依次到 Public.h 最后才到我们自己编写的文件。
(3) 检查无效引入文件,避免引入到没有使用到的文件,发现应及时清除。

2.

头文件名必须采用一致的前缀开头, 加上其代表相关类名代表的形容词即可。尽量不要使用缩写,宁愿名字稍微长点儿,也要让其有一目了然的效果。
声明相关的类扩展和协议时,必须将其声明放在主类文件夹里面,这样阅读起来相对方便。
如果有多个功能相似的类,可以考虑将其划分为一个框架,使用 .h 文件进行声明管理。