为什么强调代码风格
不同的语言，不同的项目，都有自己的风格，就像每个人都有自己的特点一样。
代码风格是一个不容易引起注意，但又回避不了的问题。一个人独自开发的工作，对代码风格是没有明显感知的，但一群人一起开发就不一样了。当吐槽别人代码的时候，或为自己几个月前的代码汗颜的时候，很可能是因为代码风格上有了分歧，该引起所有人注意了。
一个项目代码风格的确立和维护，都是需要耗费时间和精力的，但从下面几点好处看，维护代码风格是件高收益的事：
- 提高阅读代码效率
- 减少语法、逻辑理解的歧义，方便更快了解别人的代码，减少沟通成本
- 杜绝了以后关于大括号是否需要换行等风格问题的低效争论，团队更加和谐
- 新人依据确立的规范快速融入协作，减少刚入手时容易犯的错误（因为前人踩过的坑可能已总结成规范）
- 保持心情愉悦…
代码风格内容
此处讨论的是一个具体项目的代码规范，这样的规范就应该在项目组内经讨论确立后以文档方式储存，方便成员查看和优化。
文档要求尽可能精简，不能事无巨细地罗列所有规则，只需挑出视觉效果最明显、最基础的那部分规范。规范可包括以下几项内容：
- Objective-C/Swift基本编码规范
网上可找到较多详细的规范参考文档，比如： Objective-C-Coding-Guidelines-In-Chinese , Objective-C编码规范[译] 。
不需要完全照搬别人总结的规范，对其适当增删后采用。 - 本项目专属的一些编码约定
比如Debug Log的输出格式，代码行最长字符数限制，类的前缀名，文件、文件夹命名组织方式等（“对程序员而言，命名就是工作的本质，函数名、变量名、方法名、属性名、类名和框架名等都必须具备”）。 - 项目内一些功能模块的使用、编写规范
常用工具类、管理类的梳理总结，客户端生成文件夹的结构，数据库字段描述等。
后面两条的内容可以说已经超出了代码规范的内容，但对减少大家沟通、学习成本是有益的，其内容可以不放在代码规范中，但同样需要文档归纳总结（虽然大家都不愿写文档，但这样的文档的作用绝对不比代码少）。
风格的确立
一个组里组代码风格的确立，一定是一个大家一起商讨的过程。
一般先由个别成员（有时候1个人的效率>多个人）结合项目旧有的代码、编程语言的特点进行整理后，大家再一起讨论进行删减补充。
商讨过程少不了半天时间，期间怎么吵都可以，但最终大家要达成一致意见。讨论结束后，持有不同意见的人也得遵守已成文的规范，所以大括号是否该换行这类问题就要放在这个时候激烈碰撞。
没有最好的规范，只有大家普遍认可的规范。
维护规范
确定一份规范文档，只完成了统一代码规范的一半工作，更重要的另一半，就是践行该规范了。
谁都有习惯一时改不过来的情况，更有编程尽兴就不注意多写或少输入了一个空格的时候，所以Code Review的一大任务，就是细致检查队友是否遵循了规范，几次下来大家就都长记性了。但是风格错误的检查，应该只是前几次Code Review的重要内容，之后的Code Review就不应再过多谈论这些小细节了。
至于老代码是否需要按新规范来改，建议还是别动，工程可能非常巨大。当做新功能需要修改到老代码时，顺手改改那一块代码就行。
再就是代码规范的更新，虽然这种文档内容一般不容易有大的变动（除非像Objective-C转Swift之类大动作），但真要新增规范、或者剔除一些老旧规则时，要积极提出修改建议，及时更新文档。
挖个坑下篇文章再总结下现在养成习惯遵守的一些编码规范。
