作者 | 老峰

责编 | 郭芮

一直以来，关于“代码规范”的话题都备受关注，业界甚至有很多流传甚广的段子不断调侃之。既然代码规范能引起这么大的共鸣，那么今天我们谈谈一个程序员的自我修养——如何写出优雅的代码？

Martin（Bob大叔）曾在《代码整洁之道》一书中说：当你的代码在做 Code Review 时，审查者要是愤怒地吼道：“What the fuck, is this shit?”、“Dude, What the fuck！”等言辞激烈的词语，那说明你写的代码是 Bad Code，如果审查者只是漫不经心的吐出几个：“What the fuck?”，那说明你写的是 Good Code。

衡量代码质量的唯一标准就是每分钟骂出“WTF”的频率。

代码不规范会有哪些痛点？

影响团队合作，降低效率。对于共同完成项目的团队而言，如果没有统一的代码规范，最终整合代码时可能会出现看不懂命名或者阅读过程不断询问的情况，导致团队效率低下，甚至造成成员之间的矛盾。例如 git push -f，把别人的劳动成果全部覆盖掉，出现一次就会遭到全员围攻，猪队友啊......

提高维护成本。代码不规范导致可读性降低，后期的代码维护会耗费更多人力甚至财力成本.一旦代码越来越多，最后的维护就难以为继，会给运维人员造成很大负担。

引发各种 bug。如果输入输出参数、异常处理、日志处理等没有规范，很容易导致大量低级 bug，还很难找到 bug 的原因。

不利于代码审查，甚至造成安全漏洞。代码审查是纠正代码错误，保证开发周期安全顺利进行的重要一步。如果代码不规范，就会加重代码审查的工作量和难度，导致代码审查工作没有根据还浪费时间。某些情况下，代码不规范还会造成安全漏洞，此前 Morpheus 智能合约爆出的重大安全漏洞，就是大小写错误造成的。

不利于程序员自身的成长。有些人可能没有意识到代码规范的重要性，有些人意识到了但由于项目时间紧、流程繁琐等原因而不去遵循。这跟当前开发流程与安全之间的关系很像。很多人为了速度而牺牲前期的必要流程，却给后续的工作带来了更多麻烦。其实，规范的代码有助于理解开发语言、模式和架构，也有利于提升开发水平。

X，哪个蠢货写的代码！一看注释，author是自己......如果你发现你之前的代码很low，说明你已经进步了。那么如何写出优雅的代码？

如何写出优雅的代码？

1、采用规范

每种语言都有自己的推荐风格，如Swfit最近有Google Swift Style Guide，显然OC与Swift有着不同的风格。当我们开始写Swift，首先要注意的就是按照Swift的风格写，而不是沿用OC的风格，组内应该形成一种公认统一风格以便于后期维护。

从规范目标细节的角度，代码规范分为：

注释、命名、缩进空格、语句格式、规模、可靠性、语言特殊项。

2、Code Review

一份优雅、干净、整洁的代码通常自带文档和注释属性，读代码即是读作者的思路。我们在Review的过程中会发现很多不够优雅的代码，命名不规范者or影响性能，甚至存在致命bug。那么如何在团队内推行Code Review呢？我分享下我们组内目前采用的形式。

我们团队内部采用Gitlab工具，在开始一个新的迭代后，每个同事为自己负责的模块建立一个独立分支，各自在自己独立的分支完成开发，功能开发完成后，在Gitlab提交Merge Request，如果与其他同事模块有依赖，或者业务较为复杂，可分为小的功能点多次提交；负责Code Review同事Review的时候应该先让提交者讲一下大概设计的思路，在GitLab中指出存在优化的点，待提交者修改完毕后再将该分支合入主干分支。

引入Code Review的机制在一定程度上可以提升团队内代码质量，也可以减少低级bug的出现，对组内交叉熟悉彼此业务也有好处。

3、Code Lint

可能尽管我们推行了统一的代码规范，也进行了CodeReview，我们会发现只要团队成员足够多，每位成员都有不同的背景，纯靠人肉难免依然有不规范的代码存在，那么这个时候就应该采用Code Lint了。每种语言应该都有自己的编译器对应的插件，以iOS为例有SwiftLint 、ocLint，这里我简单介绍下我们团队内部使用的SwiftLint。

SwiftLint可以看作是一个Xcode插件，基于Sourcekit & Clang AST的应用（Sourcekit & Clang AST这里不做过多介绍），通过语法规范检查，可以在编译期将所有不符合Swift规范的代码全部用warning标注出来，一些严重的违背规则的代码甚至让它无法通过编译（万里江山一片黄）。

SwiftLint安装很方便，Homebrew brew install swiftlint即可安装好，然后为Xcode添加Run Script Phase。

接下来编译，就可以看到99+ warning（如下图所示）。请不要惊慌，我们可以使用swiftlint autocorrect自动解决部分警告，也可以通过.swiftlint.yml配置符合团队规范的规则，通过编译器检查规范比人肉检查更加准确高效细致，团队内部也可以做到高度统一的 Code Style。

4、阅读学习交流分享

总结绝大多数开发者的日常，对新功能开发的迫切远远大于重构一个旧的功能，导致很多代码都没有很好的版本迭代。慢慢的，破旧、破损的模块让人觉得似乎无人照管，于是别人也不再关心，最终自己也参与破坏活动，走上一条打补丁的不归路。

其实从一开始，我们就应该抱着一种重视自己的代码的态度来写代码，而不是想着先完成功能，以后再来重构优化，代码如生活：稍后就等于永不。如何保持代码整洁，离不开设计模式和代码重构，多阅读开源社区的代码，比如最近微信开源的MMKV就可以读来学习，像世界同行大佬学习交流如何优雅的写代码，也可以读一些经典的书籍如《代码整洁之道》、《重构改善既有代码的设计》、《重构改善既有代码的设计》等等。

声明：本文为公众号 iOSTips 投稿，版权归对方所有。