关注我，每天分享一个关于 iOS 的新知识
前言
前面介绍了如何在项目中使用 SwiftLint，感兴趣可以先去读一下。
SwiftLint 发展到现在已经有超过 200 条规则，每条代码规范都有其考量之处，或因为美观、或因为性能、或因为安全，看完这些规则我觉得有很多是值得我们学习的，今天就来分享一些我认为比较好的代码规范。也可以作为日常 CodeReview 的规范。
1、colon
这个规则要求，声明的冒号左边没有空格，右边有一个空格。指定类型时，冒号应位于标识符旁边，如果在字典中使用应位于 key 旁边。
2、comma
这个规则要求，逗号前面不能有空格。
3、trailing_whitespace
每行结尾不能有不必要的空格或制表符。这有助于保持代码清洁和一致。
4、force_cast
不允许使用强制类型转换，不循序强制解包。这是因为强制解包可能会导致程序在运行时 crash。
5、force_try
不允许使用强制 try，和强制类型转换一样，强制尝试可能会导致运行时错误。
6、line_length
限制每一行代码字符的长度，默认情况下超过 120 个会报警告，超过 200 个会报错，可以通过配置文件来更改默认值。这有助于提高代码的可读性。
7、function_body_length
限制函数体的长度，默认情况下超过 50 个字符会报警告，超过 100 个会报错。过长的函数体通常很难理解和维护。
8、type_body_length
限制一个类的行数，默认情况下超过 250 行会报警告，超过 350 行报错。过长的类型体可能表示类型过于复杂，应该考虑进行拆分。
9、cyclomatic_complexity
限制函数体的行数，默认情况下一个函数超过 10 行会报警告，超过 20 行报错。函数体的行数过多通常意味着函数过于复杂，不容易理解，需要重构。
10、identifier_name
检查标识符名称的长度和格式，包括变量名、常量名、类名等，默认情况下，低于 3 个字符会报警告，低于 2 个字符会报错，高于 40 个字符报警告，高于 60 个字符会报错。
合适的命名规则可以提高代码的可读性和理解性。
11、implicit_getter
计算属性和下标应避免使用 get 关键字，如果属性只有 get 方法，没有 set 方法，那么这个 get 应该省略。这样可以提高代码的可读性。
12、large_tuple
限制元组的成员数量，默认情况下超过两个会报警告，超过三个会报错。过大的元组可能导致代码难以理解和维护，应该考虑转换成自定义结构体或者类。
13、nesting
限制类型、枚举和结构体的嵌套层次，我们都知道，在 swift 中类型的声明和函数的声明是可以嵌套的，但是当嵌套层级过深可能导致代码难以理解和维护。这个规则限制类型最多嵌套 1 级深度，函数嵌套最多 2 级深度。
14、private_outlet
从 XIB 拖出来的 IBOutlet 属性应该被标记为私有（private），以避免将 UIKit 泄漏到更高层，这个主要是提高代码的封装性。
15、redundant_optional_initialization
不必要的可选初始化应该被移除，比如 var str: String? = nil，这里的 str 默认值就是 nil，因此在初始化时应该删除 = nil。这可以防止代码的冗余。
16、redundant_nil_coalescing
检查是否存在不必要的 nil 合并操作。比如：
go
var str: String?
print(str ?? nil)str 的值本身可能就为 nil，所以 ?? nil 是没有意义的。移除冗余的 nil 合并可以提高代码的可读性。
17、switch_case_alignment
switch 和 case 应该保持对齐。这可以提高代码的可读性。
18、trailing_comma
应避免/强制使用数组和字典中的尾随逗号，在多行数组和字典字面量中，最后一个元素后面不应该有逗号。这是多余的。
19、unused_closure_parameter
闭包中未使用的参数应替换为下划线 _。这可以提高代码的可读性。
20、unused_import
未使用的 import 应该被移除。这可以避免不必要的依赖。
21、vertical_whitespace
检查是否存在过多的空白行，默认情况下只允许有一行空白行。过多的垂直空白一是没必要，二是会影响代码的可读性。
22、reduce_boolean
应该用 .allSatisfy() 函数代替 reduce(true)，用 .contains() 代替 reduce(false)，因为这样可读性好，并且执行效率高。
23、empty_count
判断数组或者字符串长度为 0 时，应该用 isEmpty 属性，而不是 .count == 0，这是因为 isEmpty 属性的实现性能更高，基本上是 O1，但是有些集合的 count 属性复杂度为 O(n)。而且 isEmpty 可读性也更好一些。
24、force_unwrapping
强制解包可能会在线上导致崩溃，平时写代码时应该禁止使用。
25、reduce_into
应该用 reduce(into:_:) 代替 reduce(_:_:) 考虑到 copy-on-write 的特性，reduce(into:_:) 函数的执行性能更高。
26、toggle_bool
操作 Bool 类型时，应该用 someBool.toggle() 代替 someBool = !someBool，前者更具可读性。
最后
SwiftLint 逐渐发展成了一个庞大的项目，规则也在随着 Swift 的进化而变更，其实今天列出来的是我日常印象比较深刻的，还有很多规则也非常有用，大家可以自行看文档摸索一下。
这里每天分享一个 iOS 的新知识，快来关注我吧
本文同步自微信公众号 "iOS新知"，每天准时分享一个新知识，这里只是同步，想要及时学到就来关注我吧！