重视我，每天共享一个关于 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 兼并操作。比方：
varstr: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新知”，每天按时共享一个新知识，这儿只是同步，想要及时学到就来重视我吧！
