为什么强调代码风格

不同的语言,不同的项目,都有自己的风格,就像每个人都有自己的特点一样。
代码风格是一个不容易引起注意,但又回避不了的问题。一个人独自开发的工作,对代码风格是没有明显感知的,但一群人一起开发就不一样了。当吐槽别人代码的时候,或为自己几个月前的代码汗颜的时候,很可能是因为代码风格上有了分歧,该引起所有人注意了。
一个项目代码风格的确立和维护,都是需要耗费时间和精力的,但从下面几点好处看,维护代码风格是件高收益的事:

  • 提高阅读代码效率
  • 减少语法、逻辑理解的歧义,方便更快了解别人的代码,减少沟通成本
  • 杜绝了以后关于大括号是否需要换行等风格问题的低效争论,团队更加和谐
  • 新人依据确立的规范快速融入协作,减少刚入手时容易犯的错误(因为前人踩过的坑可能已总结成规范)
  • 保持心情愉悦…

代码风格内容

此处讨论的是一个具体项目的代码规范,这样的规范就应该在项目组内经讨论确立后以文档方式储存,方便成员查看和优化。
文档要求尽可能精简,不能事无巨细地罗列所有规则,只需挑出视觉效果最明显、最基础的那部分规范。规范可包括以下几项内容:

  • Objective-C/Swift基本编码规范

网上可找到较多详细的规范参考文档,比如: Objective-C-Coding-Guidelines-In-Chinese , Objective-C编码规范[译]
不需要完全照搬别人总结的规范,对其适当增删后采用。

  • 本项目专属的一些编码约定

比如Debug Log的输出格式,代码行最长字符数限制,类的前缀名,文件、文件夹命名组织方式等(“对程序员而言,命名就是工作的本质,函数名、变量名、方法名、属性名、类名和框架名等都必须具备”)。

  • 项目内一些功能模块的使用、编写规范

常用工具类、管理类的梳理总结,客户端生成文件夹的结构,数据库字段描述等。

后面两条的内容可以说已经超出了代码规范的内容,但对减少大家沟通、学习成本是有益的,其内容可以不放在代码规范中,但同样需要文档归纳总结(虽然大家都不愿写文档,但这样的文档的作用绝对不比代码少)。

风格的确立

一个组里组代码风格的确立,一定是一个大家一起商讨的过程。
一般先由个别成员(有时候1个人的效率>多个人)结合项目旧有的代码、编程语言的特点进行整理后,大家再一起讨论进行删减补充。
商讨过程少不了半天时间,期间怎么吵都可以,但最终大家要达成一致意见。讨论结束后,持有不同意见的人也得遵守已成文的规范,所以大括号是否该换行这类问题就要放在这个时候激烈碰撞。
没有最好的规范,只有大家普遍认可的规范。

维护规范

确定一份规范文档,只完成了统一代码规范的一半工作,更重要的另一半,就是践行该规范了。
谁都有习惯一时改不过来的情况,更有编程尽兴就不注意多写或少输入了一个空格的时候,所以Code Review的一大任务,就是细致检查队友是否遵循了规范,几次下来大家就都长记性了。但是风格错误的检查,应该只是前几次Code Review的重要内容,之后的Code Review就不应再过多谈论这些小细节了。
至于老代码是否需要按新规范来改,建议还是别动,工程可能非常巨大。当做新功能需要修改到老代码时,顺手改改那一块代码就行。
再就是代码规范的更新,虽然这种文档内容一般不容易有大的变动(除非像Objective-C转Swift之类大动作),但真要新增规范、或者剔除一些老旧规则时,要积极提出修改建议,及时更新文档。

挖个坑下篇文章再总结下现在养成习惯遵守的一些编码规范。