iOS进阶 - 如何制定一套适合自己团队的 iOS 编码规范？

Posted 2022-08-05 极客学伟

ios进阶 - 如何制定一套适合自己团队的 iOS 编码规范？

统一的编码规范，能有限的避免团队成员由于代码风格不一致而导致的相互认同感缺失的问题。

好的代码规范，需要从如下八个方面进行约束：常量、变量、属性、条件语句、循环语句、函数、类、分类

常量

在常量的使用上，建议尽量使用类型常量，而不是宏定义。比如定义一个字符串常量，可以写成：

static NSString * const kStringName = @"kStringName";

或在全局常量文件中，在 .m 文件中定义：

NSString * const KALERTMESSAGE_BLOCK_SUCCESS = @"拉黑成功";

在 .h 文件中对外声明：

UIKIT_EXTERN NSString * const KALERTMESSAGE_BLOCK_SUCCESS;

变量

1. 变量名应该可以明确体现出功能，最好再加上类型做后缀。这样也就明确了每个变量都是做什么的，而不是把一个变量当做不同的值用在不同的地方。
2. 在使用之前，需要先对变量做初始化，而且初始化的地方离使用它的地方越近越好
3. 不要滥用全局变量，尽量少用他来传递值，通过参数传值可以减少功能模块间的耦合

比如

let nameString = "极客学伟";

属性

• Objective-C 里的属性，要尽量通过 get 方法来进行懒加载，以避免无用的内存占用和多余的计算。
• Swift 的计算属性如果是只读，可以省掉 get 子句，实例代码如下：

var areaDouble : Double 
    return long * width

条件语句

在条件语句中，需要考虑到条件语句中可能涉及到的所有分支条件，对于每个分支条件都需要考虑到，并进行处理，减少或不使用默认处理。特别是 Switch 处理枚举时，不要有 default 分支。

另外，条件语句的嵌套分支不宜过多，可以充分利用 Swift 中的 guard 语法
例如这段实例代码

if let userName = login.userNameOK 
    if let password = login.passwordOK 
        // 登录处理
        ...
     else 
        fatalError("login wrong")
    
 else 
    fatalError("login wrong")

上面这段代码表示的是，当用户名和密码都没有问题时再进行登录处理，那么我们可以使用 guard 语法

guard 
    let userName = login.userNameOK,
    let password = login.passwordOK,
else 
    fatalError("login wrong")

// 登录处理
...

循环语句

在循环语句中，我们应该尽量少地使用 continue 和 break，同样可以使用 guard 语法来解决这个问题。解决方法是：所有需要 continue 和 break 的地方统一使用 guard 语法去处理，将所有的异常放到一处。这样的好处是在维护的时候方便阅读，使得代码更加易读和易于理解。

函数

对于函数来说，体积不宜过大，最好控制在百行代码以内。如果函数内部逻辑过多，我们可以将复杂逻辑分解成多个小逻辑。并将每个小逻辑提取出来作为一个单独的函数，每个函数处理最小单位的逻辑，然后一层一层往上组合。
这样我们可以通过函数名明确那段逻辑处理的目的，提高代码的可读性。
拆分成多个逻辑简单的函数之后，我们需要对函数的入参进行验证，同样 guard 语法同样适用于检查入参。

func saveRSS(rss: RSS?, store: Store?) 
    guard let rss = rss else 
        return 
    
    guard let store = store else 
        return
    

    // 保存 RSS
    return

另外，函数内部尽量避免使用全局变量来传递数据，使用参数或者局部变量传递数据能够减少函数对外部的依赖，减少耦合，提高函数的独立性，提高单元测试的准确性。

类

在 Objective-C 中，类的头文件应该尽可能少的引入其他类的头文件，可以通过 class 关键字进行声明，然后在实现文件里引入需要的其他类的头文件。
对于继承和遵循协议的情况，无法避免移入其他类的头文件，所以在代码设计时还是要尽量减少继承，特别是继承关系太多时不利于代码的维护和修改，比如说修改父类时还需要考虑对所有子类的影响，如果评估不全，影响就难以控制

分类

在写分类时，分类里增加的方法名要尽量加上前缀，而如果是系统自带类的分类的话，方法名就一定要加上前缀，来避免方法名重复的问题。
分类适合多人负责同一个类时，根据不同分类来进行各自不同功能代码的维护。

Code Review

在代码进行 Code Review 之前，可以先使用静态检查工具对提交的代码进行一次全面检查。

如果是 Swift 语言的话，可以使用 SwiftLint 工具来检查代码规范，

如果是 Objective-C 可以使用 OCLint 使用 OCLint 自定义 MVVM 规则
来做代码规范检查。

最后是 人工检查

对于代码规范不需要过于复杂，只要坚持能够 让代码逻辑清晰 这个原则就可以了，剩下的所有规则都围绕这个原则来。代码逻辑清晰是高质量的代码工程最基本、最必要的条件，如果代码不清晰的话，那么其他的扩展、重用、简洁优雅都免谈。