我相信每一个程序都有一个追求优秀代码风格的梦想。
梦想自己的代码就如武林绝学般简练，威力无穷；如诗句般优美，无可挑剔。
1 代码架构
从代码架构说起。
严格来说，代码架构不是代码风格的一部分，但是很多时候我觉得他们密不可分。
比如要实现一个逻辑稍微复杂的模块，按照直线思维，可以用一个函数实现。这会导致整个函数极其冗长，里面if/else一大堆，可读性不友好，更不易扩展。
这本质上是代码架构不够好，应该在设计时拆解成几个逻辑小模块，每个小模块实现明确的功能要求。从可读性上来讲，这又是一个代码风格的问题，原则上一个函数不要过长，在一个屏幕界面内能完整显示最佳。
下面是我认为代码架构中比较重要的几点，特别是在大型项目代码中其重要性尤为凸显。
1.1 独立性
减小各功能模块之间的耦合性。
每个模块实现的功能尽可能单一且清晰明确，这样各个模块耦合性就会比较小；否则几个模块我中有你，你中有我，改动起来牵一发动全身，这就很不可取。
独立性不仅易于阅读，更是对整个项目代码能够稳定运行起着至关重要的作用。特别是后期，如果独立性不强，加上各种补丁，整个代码就是一团乱麻。
我们很多时候都说自己就是公司的一颗螺丝钉，换一个人同样能做这个工作，不影响大局，就是这个道理。但是如果你即管理仓库，又当老板的司机，还兼写代码，那么换掉你就不那么容易了。
1.2 扩展性
增加新的功能，代码改动量最小。
举个简单的例子，你写一个模块实现一个十字路口的红绿灯闪烁逻辑，但是如果加上一个黄灯，你的代码得推导重来，那么这个代码就不具有可扩展性。
就像建一座高楼大厦，首先要把地基打好，把框架搭好，这样才能一层一层往上盖。而不是等到盖到第四层，才发现地基可能承受不了。当然实际盖房子我们预先知道房子要盖多高，但是我们设计功能模块时我们无法预知，一代一代迭代下去，要有充分得可扩展性，就要求我们开始的设计要足够好。
扩展性尤为重要得原因在于，让代码可迭代，减少重复性工作。而不是新来一个需求，整个模块推导重来。
1.3 可复用
其他模块可之间调用。
如果是公用得模块，就得考虑可复用性了。而不是我要这个功能得时候写一个模块，但是别人又不好调用，然后又写一个类似功能得模块。
比如模块A要或者某个长方体的体积，写了一个函数返回体积；模块B要获取底面积，模块C要获取侧面积，又写了两个函数；实际上一个函数返回长方体的长宽高就可以解决问题。
1.4 完整性
不仅要实现功能，还要考虑各种异常情况。
模块不仅要考虑正常情况，而且在遇到异常情况是要有打印或者抛出异常；否则一旦出问题，会大大增加debug的成本。
刚开始设计好是一次性维护成本，但是如果等到出问题可能就是几倍的成本。
2 代码风格
可参考Google C++ 编程规范。
2.1 文档与注释
优秀的设计文档要要达到下面几个要求：
- 明确模块的需求来源和功能作用；
- 设计思想；
- 重点部分的说明；
这样，在不看代码的情况下，基本上有个70-80%的了解了。
关于注释。
网上有各种说法，比较前卫的思想是，没有任何注释且能够让读者读懂的代码才是合格的代码。我对此持保守态度。
我的看法是，尽可能用规范的命令以及清晰的架构让读者尽可能能够明白，在此基础上减少注释，而不是没有任何注释。
所以，除去以下几种情况其他情况都不必要注释：
- 函数前的对于函数功能的注释；
- 逻辑比较复杂的重点处注释。
2.2 命令规范
这一点网上的文章也比较多，我认为主要思想是：
- 看到函数名或者变量名就能够知道它的作用！
这也是加强代码可读性的核心部分之一。
我个人的习惯是：
2.2.1 函数命令
Xxx1_Xxx2_Xxx3
Xxx1: 首字母大写，一级模块名称；
Xxx2: 二次模块名称；
Xxx3: 函数功能，尽可能三四个单词说明白；
2.2.2 变量命令
全局变量：XxxYyy, 大驼峰法；
局部变量：xxxYyy，小驼峰法；
总体原则是避免无意义的命名。
2.3 一致性
一个项目代码要遵循同一套代码规范，可以大大减少后期维护成本。
3 结语
优秀的代码真的赏心悦目，愿我们都能写出让自己骄傲的代码。