源码即设计：程序员也是时尚大师

我们经常谈论架构，讨论设计，却甚少关注实现和代码本身，架构和设计固然重要，但要说代码本身不重要，我不同意，Robert C.Martin大叔也不同意，Martin认为“源码即设计”。

在讨论具体的实施细则之前，我们不妨讨论一下什么是好代码？萝卜特 C.Martin认为：衡量代码质量的唯一标准是：WTF/min，也就是review代码的时候每分钟说“握草”的次数。这个定义虽有辱斯文，但粗野中不失奔放，调皮中又蕴含哲理。

好的代码如同文笔优美的散文，行云流水，赏心悦目，阅读的时候，如沐春风，带给人愉悦与启迪。

好的代码犹如构思精巧的小说，它或许不够平铺直述，却足够引人入胜，读到最后，你会豁然开朗，我去，原来是这样的啊，那一刻，你会觉得过程中的曲折和探索都是值得的。

好的代码，透过一个个函数，你仿佛可以窥视到作者有趣的灵魂；透过一行行代码，你仿佛在与一个充满智慧的朋友聊天，她总是条理清晰，逻辑严谨，有条不紊，娓娓道来。

而坏的代码，犹如病毒，它不仅瘫痪你的程序，还有很强的传播效应，等到它扩散开来，神仙难治。

坏的代码，像一个泥团，阅读的时候，你仿佛被困于黑暗的迷宫，又仿佛在跟一个絮絮叨叨的人交谈，她的脑回路经常短路，说话含混不清，主次不分，叨逼半天，你依然get不到她的中心思想，你常常感觉智商受到了莫大的侮辱，你面露艰难神色，心中万马奔腾。

有很多区分好坏代码的规则，我也看过一些，对于文章中提到的一些标准做法，就不重复嚼舌头根子了，我想结合自己的工作经历，谈一谈自己的切身体会。

闲扯半日，言归正传，要编写弥漫好味道的代码，要遵循哪些约束和指引呢？

一致性

持之以恒的遵从一致性规则，在代码风格上，争论个三天三夜估计也定不出个好坏出来，但好的风格一定是强一致性的，这一点应该比较容易达成一致吧?风格的好坏其实更多受习惯的影响，头发少一点的程序员应该都有自己风格变迁的经历，多年前自己笃信不疑的good style或许正是当前深恶痛绝的bad style，所以我主张在style上搁置嘴炮，一个项目应该有一个编码规则，好的规则应该是以理服人的，好的规则应该是拒绝任性夹带私货的，规则定了之后，就遵照执行吧，可能某个风格跟你不相符，但没关系，你要知道，这并不意味，你在style之战败下阵来，也并不表示它说服了你，你遵守的是规则和纪律本身。

变量（包括文件、类/结构体、函数）命名，比如ohmygod，你可能搞不清哪些字母是一伙的，所以需要界定单词。驼峰通过单词首字母大写来界定单词，另一个惯用做法是用下划线拼接单词。驼峰的弊端是丑，下划线拼接的弊端是增加了标识符长度（相比首字母大写），好处是跟std c/c++、linux kernel的做法一致，喜欢kernel的码农容易找到如家般的归属感。

c++有namespace避免冲突，c经常用prefix防止命名污染全局空间，但我认为命名简洁扼要很重要，所以我支持简短的前缀而反对冗长的前缀。

代码密度

实现同样的功能，你喜欢100行代码，还是20行代码？如果贵leader不以代码行数考核绩效我建议你把代码写的精简，而如果贵leader以代码行数考核绩效，我建议你转行，开滴滴，送外卖或者摆摊都行，因为在这样的leader下面耗费青春基本上也不会有什么发展前途。

把简单的东西搞复杂化很容易，你只需要找一个能力平庸的人就能实现化简为繁的愿望，而化繁为简则堪称化腐朽为神奇。也许你要说，我欠缺简化的能力，这并不奇怪，坦白讲，这不是一件容易的事，你做不到没关系，但你拥有正确的理念更重要，它将帮助你认清前进的方向，而不是在错误的道路上越走越远。

有些项目，充斥各种无效代码，其实你只需要稍加思考，你就能识别出来。

比如大块注释掉的代码像发臭的尸体一样遍布其中。比如大量功能重复的代码像垃圾一样堆砌在那里。比如本不需要返回值的函数恒定的返回true。

又或者函数一进来，不管三七二十一，对入参一顿检查，全然忘记你在编写的是一个私有实现函数，你在调用它之前已经检查过一遍，私有函数是一个受控的安全上下文，这不仅不优雅而且不绿色（低效耗电）并且不安全（在该崩的时候没崩把雷埋到了更隐蔽的地方），话说你看标准库函数strcpy/strcat，vector operator[]检查传参了吗？

提高代码密度或者说浓度有利于理清思路，有利于突出重点，有利于提高维护性，而充斥各种无效语句的代码只会把关键语句淹没在汪洋大海，使得review代码的人get不到重点，看不清主次。像听一个絮絮叨叨的人做报告，满篇废话，像看一个剧情拖沓的连续剧，昏昏欲睡，像喝一瓶二锅头兑十斤白开水，口能淡出个鸟来。

重构是程序员的口头禅，重构是在保持程序功能不变的情况下调整架构和实现，我认为提高代码密度应作为重构的一项追求。

linux kernel、lua、nginx、skynet这些优秀的开源库代码浓度都很高，建议读者朋友品尝一下。

封装

我们最常干的一件事就是把重复编写的代码封装到一个函数里去，用多处调用替代重复编写，这个很好理解，但其实即使不被多处调用，把相关的一段代码封装到一个实现函数也是有必要的，因为把代码平铺开来，把细节暴露出来，容易掩盖重要的东西，即框架和脉络会变得不够清晰。

一个见名知义的函数调用比堆砌在那里的一段代码给我的感受好，我如果关心它是怎么做的，我可以跳转到定义看看实现。

封装的一个核心原则是单一职责，符合单一职责的函数更易于被复用。

避免特例

linus大神分享过他心中的好代码，说的是针对链表的操作，他更喜欢统一性的处理方式，而不是做特例化的处理，我想这个例子很有代表性，它其实代表一种理念，那就是自始至终，我们的头脑里必须优先考虑normal化的处理方式，当然这其实是一个比较高层次的要求，菜鸟互啄可以先跳过这一层要求。

缩写

慎用缩写，相比缩写带来的含混不清，我宁愿多敲几下键盘，如果要缩写请符合惯例遵从常规，比如AI，比如App，比如cfg，但是你把threshold缩写成threshod，把Item缩写成Iem，我特木真的搞不懂这是拼错了还是缩歪了？

解耦

构建松散耦合的系统一直是软件工程的一个目标，模块化的一个方向便是解耦，但我们口口声称心心念想的解耦，在实施层面又有几分体现呢？

比如，我经常干的一件事就是把类似配置文件，或者宏定义的东西集中的一个头文件里去，看起来很统一也很正规，起码我之前也是这样认为的，但忽然有一天，发现自己这样做显得很不聪明的样子，为什么呢？因为你想把所有模块配置相关的东西都塞进配置公共文件真的合适吗？是不是把公共接口抽离出来更好，把配置相关的数据下沉到各模块更合适？

另外，把宏都定义到一起，这意味随便改点东西，都会需要修改宏头文件，而这个头文件就会成为程序世界的中心，修改公共宏文件几乎会引起整个系统的所有源文件rebuild，这简直就是AOE团灭啊。所以更好的方式是分而治之，去集中式。

我们知道c/c++的编译单元是source file（.c/.cpp），编译的第一步是预处理，所有include都会展开替换，所以我们要避免引入任何不必要的头文件，也应该把本编译单元用到的头文件都include进来，这就是所谓的头文件自给自足。这点很重要，但很多人会不以为然，甚至有些人会自作聪明的搞一个allincluded.h，把常用的一些头文件全部include进来，然后自认为一劳永逸的完美的解决了问题，包含不必要的头文件会增加编译时间，会增加依赖，我们不仅应该避免错误的包含，还应该精心设计和划分文件，使得每个文件的功能足够内聚单一。

遵从标准

我遇到每个模块单独定义自己的各种原生（build-in）数据类型，但我建议不要这样做。如果你只是需要解决不同体系结构下long等整型的长度差异，我想告诉你，c库头文件stdint.h已经从标准层面统一解决了这个问题，里面int8_t/16_t/32_t/64_t，还有uint8_t等等应有尽有。

宏

宏是c的一个有效武器，在有些情况下确实行之有效，关于宏，我是骑墙派，我既反对禁用宏，也反对滥用宏，inline可以部分替代宏，但不能完全替代宏。

如果项目里到处都是宏，全大写，至少1/3的代码都是各种诡异的宏，你review代码的时候，不停的跳来跳去，看了一眼，哦，就这样啊，然后切回来，频繁的上下文切换是低效的，它打断了你的思路，其实很多时候完全没有必要。

命名

命名有一些指引，比如类/结构体应该用名词，函数应该用类似动词或者doSomething这样的动宾结构，这些规矩都是耳熟能详的。

我主张命名应该简明扼要，不要罗里吧嗦，要准确的表达出它要做的事情，如果你碰到命名困难，你可能需要考虑你的类定义或者接口划分是否合适。

命名是接口的一部分，很重要，好的命名是自注释的。

我反对匈牙利命名法，理由：不能一致性的解释各种类型，把类型编码进变量不合理，变量名本身就能体现它的类型，无法适用template情况，始作俑者ms放弃了它。

如果你没有思路，那我建议你参考一下STD C/C++ API，毕竟这些接口历经几十年没有大的变化，算是经受住了历史的考验，比如malloc/free/atoi，stl 容器的成员函数也有点意思：size()、 capacity()、resize()、reserve()、push()、pop()、top()、back()，很干脆，不废话，我觉得很好。

所以，如果你编写的是某某管理器，比如ItemManager，我建议你直接取名add()，remove()，而不用AddItem()，RemoveItem()，因为你本身就是Item的Manager，操作的必然是Item，而且从参数上也能体现出来，少即是多，多不如少。

扩展性

开闭原则是应对扩展性的rule，人无远虑必有近忧，说的是我们不能局限于眼前，但也请不要过度设计，不可盲目迷信扩展性，戏太多也是病。

知乎有一篇神贴讲的是如何把helloworld搞成一个big project，当你想给别人项目挑刺的时候，你可以用扩展性说事，但我建议你离开口闭口扩展性的人远一点，据我观察，这种人大多比较虚伪而且很水。

高效而鲁棒

有很多避免运行低效的做法，比如哈希、减少拷贝、提高局部性、buffer/cache、空间时间置换、内联、分支预测、判断前置、计算延迟、无锁编程。

提高鲁棒性的关键是保持简单，任何引入复杂性的动作都需要保持足够警惕。不信任/零信任设计，面向failed编程，假设依赖的上下文，上下游都是不可靠的，去中心化去关键路径，熔断，降级，避免惊群效应，方法很多，不一一列举了。