团队开发中，期望 Code Review 来约束的是代码结构和潜在逻辑问题，这时代码规范这种『细节』就给 review 过程带来不小的噪音。
特别是团队目前的情况：历史负担较重，大量经几手的旧代码风格不一致，团队成员新组建，对代码规范、好的范式还没达成默契。新写代码的规范尚在磨合中，遑论手动改写大量的旧代码。
这是重要不紧急的问题，最近项目略有空闲，是对这类问题下手的好时机；）
目标
- 提升代码可读性，打破『破窗效应』
- 用工具约束代码规范，尽可能不影响原有开发流程的同时，尽可能减少 code review 中代码规范方面的噪音，让开发精力放在该放的地方
- Reformat 历史代码，一劳永逸的解决这个问题
破窗效应
『如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。...又或想像一条人行道有些许纸屑，如果无人清理，不久后就会有更多垃圾，最终人们会视为理所当然地将垃圾顺手丢弃在地上。』
——维基百科
一些调研
本以为不会太复杂，实际执行起来发现问题也不少：
- 拜苹果的封闭和垃圾的 Xcode 所致，旧插件不可用 ClangFormat-Xcode 、BBUncrustifyPlugin-Xcode ，Xcode8 插件又未成火候，均不好用
-
XcodeClangFormat for Xcode8 调试
.clang-format并不方便 - SwiftLint 评价很高，可惜目前项目 7w lines ObjC，Swift 在下半年计划里
看了一圈，最终决定选择 square 家的方案：https://github.com/square/spacecommander
spacecommander = clang-format + ObjC 定制规范 + git 工作流
spacecommander 在 clang-format 基础上加入几条定制规范，解决了 block 缩进问题，对 ObjC 更友好。内置脚本，很方便的添加 git pre-commit hook，format 代码也算方便，不影响原有工作流。源代码很少，一些 shell 和 python，很容易看懂。
这些跟团队需要很契合，项目有些老，有些小问题，缝缝补补能用就好。
如何执行
- Fork https://github.com/square/spacecommander 项目（方便后续定制），clone 到本地
- cd 到需要格式化的项目根目录，执行
/path/to/spacecommander/setup-repo.sh。这时你会看到项目目录下创建了一个软链接.clang-format（并加入到.gitignore) 同时创建.git/hooks/pre-commit，commit 时起效果的秘密就在这里 - 随意修改项目中的一个 .m 文件，stage file，commit，你会得到这样的提示：
git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree commit -q -F /var/folders/7w/5_0xvl794n960s_wsr3h68340000gn/T/SourceTreeTemp.GSJLdQ
🚸 Format and stage individual files:
"/Users/zengming/ming-dev/gg-projects/spacecommander"/format-objc-file.sh 'ios-common/GGLib/GGBase/GGModels/GGHotelAPIModel.m' && git add 'ios-common/GGLib/GGBase/GGModels/GGHotelAPIModel.m';
🚀 Format and stage all affected files:
"/Users/zengming/ming-dev/gg-projects/spacecommander"/format-objc-files.sh -s
🔴 There were formatting issues with this commit, run the👆 above👆 command to fix.
💔 Commit anyway and skip this check by running git commit --no-verify
Completed with errors, see above
- 新修改的 GGHotelAPIModel.m 文件代码规范检查不通过，所以 commit 失败。解决起来也很容易，按上面的提示在终端输入
"/Users/zengming/ming-dev/gg-projects/spacecommander"/format-objc-files.sh -s，再 commit，搞定！
spacecommander 的原理是定制好 .clang-format，执行 commit 前运行 format-objc-file-dry-run 检查当前要提交的文件，如果不符合规范，则提示修改。（默认只检查已修改并 Stage 的文件）
如果要格式化项目所有文件，可以尝试在项目中运行 /path/to/spacecommander/format-objc-files-in-repo
一些细节问题
Block 格式化不符合预期？
参见这里：https://bugs.llvm.org//show_bug.cgi?id=23585
clang-format: Support nested block formatting with ColumnLimit=0.
改到可用，这点还不大符合我的预期。谁有更好的方法吗？
// 格式化后的效果
[UIAlertView bk_showAlertViewWithTitle:@"温馨提示"
message:push.alert
cancelButtonTitle:@"忽略"
otherButtonTitles:@[ @"查看" ]
handler:^(UIAlertView *alertView, NSInteger buttonIndex) {
if (buttonIndex == 0) {
return;
}
...
}];
// 我期望的效果
[UIAlertView bk_showAlertViewWithTitle:@"温馨提示"
message:push.alert
cancelButtonTitle:@"忽略"
otherButtonTitles:@[ @"查看" ]
handler:^(UIAlertView *alertView, NSInteger buttonIndex)
{
if (buttonIndex == 0) {
return;
}
...
}];
直接使用 .clang-format ?
最开始我也是直接配 .clang-format，总有些配置不合预期，改起来调试也不是那么方便。spacecommander 的基础配置是一个能看的配置，推荐在它的基础上改，何况 git hook 都写好了何必自己折腾。
.clang-format 全部配置细节参见这里：https://clang.llvm.org/docs/ClangFormatStyleOptions.html
spacecommander 的一些小问题
- spacecommander 一些配置是挺老的，自带的 clang-format 是 v3.8（官方最新是 v5），这点没碰到问题，略过
- 如果你运行
format-objc-files.sh -s时 python 报错，这是因为 spacecommander 定制的规则 py 使用的是 python2, 切到 python2 下运行即可 - spacecommander 其中一个定制
MacroSemicolonAppender.py格式化时会把我的文件改错（错加分号），我没细究，禁掉即可（禁掉方式参见我的 fork）
总结
- 代码规范其实是很重要的事，看整齐的代码给大家好的心情，这非常重要
- 代码规范这种重要却又琐碎的脏活累活还是交个自动化工具来解决，让团队精力集中在其它重要的事情上
- 格式化配置细节还有有些问题，关系不大，不怕工具不好，先有，再慢慢改进
- 这只是代码规范，跟代码逻辑，架构没半毛钱关系
- 代码整齐了，看着真舒服不少😄
