代码格式乱，读着像天书
第六章讲"格式"，这章看得我频频皱眉——原来那些"缩进忽大忽小、空行随心所欲"的代码，真的会影响团队效率。
格式的终极目的：方便阅读
作者说"代码格式关乎沟通"，太对了。就像写文章要分段、用标点，代码格式也是为了让读者快速get到逻辑。
想想看，同样一段逻辑：
- 乱糟糟的格式：得逐行找括号，看半天才能分清哪个if对应哪个else
- 整洁的格式：一眼就能看出嵌套关系，知道哪里是主干哪里是分支
格式好的代码，就像排版舒服的书，读起来不累；格式差的，就像满页错别字的草稿，看着就头疼。
垂直格式：像读报纸一样从上到下
书中说"源文件要像报纸"，这个比喻太形象了：
- 顶部是类名（头条），一眼就知道讲啥
- 接着是重要的方法（导语），概括核心功能
- 再往下是细节实现（正文），慢慢展开
最关键的是"垂直距离"：相关的代码要靠近。比如一个类里，变量声明应该挨在一起，调用它们的方法也该离得不远。
想起之前见过的代码，变量声明在开头，用到它的方法在几百行下面，找起来像寻宝。好的垂直格式，能让读者不用跳来跳去。
横向格式：别让代码"撑破屏幕"
作者建议代码行长度控制在120字符以内，我深以为然。现在显示器再大，一行塞太多东西，眼睛也得左右扫，累得慌。
横向格式的关键是"区隔与靠近"：
- 赋值符
=两边加空格，比如int total = price + tax，比int total=price+tax清楚 - 运算符两边加空格，比如
a + b * c，别写成a+b*c - 函数参数用逗号隔开，每个参数单独换行（尤其参数多的时候）
最坑的是见过一行代码写了三四个逻辑判断，if ((a > b && c < d) || (e != f && g == h))，盯着看三分钟才理清优先级。横向格式的核心，是让代码的逻辑层次肉眼可见。
团队规则：格式要统一，别各搞一套
作者说"团队应该一致同意采用一套格式规则"。以前觉得"格式凭个人喜好"，直到和同事协作时栽了跟头：
- 我习惯缩进4格，他习惯2格，合并代码时全是冲突
- 我用
if()后面换行，他喜欢if()紧跟大括号，看着就别扭 - 最后花了半天时间统一格式，纯属浪费时间
现在明白了，格式就像团队的"方言"，统一了才能顺畅沟通。好在现在IDE都能自动格式化，把规则配置好，谁写的都一样。
最后试了个小改变
把自己的代码按书中建议调整了格式：
- 相关函数放一起，调用者在上，被调用者在下
- 变量声明靠近使用的地方
- 长行拆成多行，每个逻辑块单独放
- 空行隔开不同的概念
结果同事说"你最近的代码看着真舒服"。原来格式这东西，看着不起眼，影响却很大。毕竟，没人愿意读一篇排版混乱的文章，同理，没人愿意读格式糟糕的代码。
（下一章讲对象和数据结构，想起自己写的"又像对象又像结构体"的类，感觉要被暴击了...）
