我们经常谈论架构，谈论设计，却甚少关注实现和代码本身，架构和设计固然重要，但要说代码本身不重要，不仅我不同意，Robert C.Martin大叔也不同意，大叔认为“源码即是设计”。
在讨论具体的实施细则之前，我们不妨讨论一下什么是好代码？萝卜特（Martin）大叔认为：衡量代码质量的唯一标准是：WTF/min，也就是review代码的时候每分钟说“握草”的次数。这个定义虽有辱斯文，但粗野中不失调皮，调皮中又蕴含哲理。
好的代码如同文笔优美的散文，行云流水，如沐春风，阅读的时候，赏心悦目，带给人愉悦与启迪。
好的代码犹如构思精巧的小说，它或许不够平铺直述，但足够引人入胜，读到最后，你会豁然开朗，哦，原来是这样的啊，那一刻，你会觉得过程中的曲折和探索都是值得的。
好的代码，透过一个个函数，你仿佛可以窥视到作者有趣的灵魂，透过一行行代码，你仿佛在与一个充满智慧的朋友聊天，她总是思路清晰，逻辑严谨，娓娓道来。
而坏的代码，就像一个泥团，或者像一摊屎，阅读的时候，你仿佛被困于黑暗的迷宫，又仿佛在跟一个絮絮叨叨的人交谈，她的脑回路经常短路，说话含混不清，主次不分，叨逼半天，你依然get不到她的中心思想，你感觉智商受到了莫大的侮辱，甚至感觉像被人喂吃shit，你面露艰难神色，心中万马奔腾。
有很多区分好代码坏代码的规则，网上的文章也很多，我也看过不少，对于文章中提到的一些守则，就不重复嚼舌头根子了，我想结合自己的工作经历，谈一谈自己的体会。
闲扯了半天，言归正传，要编写弥漫好味道的代码，要遵循哪些约束和指引呢？
一致性
持之以恒的遵从一致性规则，在代码风格上，争论个三天三夜估计也定不出个好坏出来，但好的风格一定是强一致性的，这一点应该比较容易达成一致。风格的好坏其实更多受习惯的影响，年长一点的程序员应该都有自己风格变迁的经历，多年前自己笃信不疑的good style或许正是当前深恶痛绝的bad style，所以我主张在style上搁置嘴炮，一个项目应该有一个编码规则，好的规则应该是以理服人的，好的规则应该是拒绝任性夹带私货的，规则定了之后，就遵照执行吧，可能某个风格跟你不相符，但你要知道，这并不意味，你在style之战败下阵来，也并不表示它说服了你，你遵守的是规则和纪律本身。
我经历过一些c的项目，函数命名有大驼峰，有小驼峰，有下划线连词，还有驼峰夹下划线（有些是两个），还有函数名下划线或者两个下划线开头，总结一下它的规律就是没有规律，非常随心所欲，令我莫衷一是。
变量（包括文件、类/结构体、函数）命名，比如ohmygod，你可能搞不清哪些字母是一伙的，所以要界定单词，驼峰就是单词首字母大写来界定单词，另一个做法是用下划线拼接单词。下划线拼接的坏处是增加了标识符长度（相比首字母大写），好处是跟std c/c++、linux kernel的做法一致，喜欢kernel的码农容易找到如家般的归属感。
因为c++有namespace，所以c经常用prefix防止命名污染全局空间避免冲突，但我认为命名简洁短小很重要，所以我支持简短的前缀反对冗长的前缀。
代码密度
实现同样的功能，你喜欢100行代码，还是20行代码？如果贵司不以代码行数考核绩效我建议你把代码写的精简，而如果贵司以代码行数考核绩效，我建议你离职，开滴滴，或者送外卖都行，因为在这种公司耗费青春不会有什么发展前景。
把简单的东西搞复杂化很容易，你只需要找一个能力平庸的人就能实现化简为繁的愿望，而化繁为简则堪称化腐朽为神奇。也许你要说，我欠缺简化的能力，这个不奇怪，坦白讲，这不是一件容易的事，你做不到没关系，但你拥有正确的理念更重要，它将帮助你认清未来的方向，而不是在错误的道路上越走越远。
有些项目，充斥各种无效代码，其实你只需要稍加思考，你就能识别出来，比如本不需要返回值的函数，执拗的固定返回true，然后在调用的地方还要装模作样的check一下返回值，如果返回false，再记一条日志，再assert一下，再抛个异常，这样显得自己很有职业操守，美其名曰面向failed编程，处理了各种异常情况；又或者函数一进来，不管三七二十一，对入参一顿无脑检查，宣称这是符合ISO SB标准的安全做法，全然忘记你在编写的是一个私有实现函数，你在调用它之前已经检查过一遍，私有函数是一个受控的安全上下文，这不仅不优雅而且不绿色（低效耗电），并且不安全（在该崩的时候没崩把雷埋到了更隐蔽的地方）。
提高代码密度或者说代码浓度有利于信息展现，有利于突出重点，有利于提高维护性，而充斥各种无效语句的代码只会把关键语句淹没在汪洋大海，使得review代码的人get不到重点，看不清主次。像听一个絮絮叨叨的人做报告，满篇废话，像看一个剧情拖沓的连续剧，昏昏欲睡，像喝一杯被十倍稀释的二锅头，口能淡出个鸟来。
重构是程序员的口头禅，重构是在保持程序功能不变的情况下调整架构和实现，提升程序可读性可维护性可扩展性，我认为提高代码密度应该作为重构的一项追求。
linux kernel、lua、nginx、skynet这些优秀的开源库代码浓度都很高，建议读者朋友体验一下。
封装和解耦
构建松散耦合的系统一直是软件工程的一个目标，模块化的一个方向便是解耦，但我们口口声称心心念想的解耦，在实施层面又有几分体现呢？
比如，我们经常干的一件蠢事就是把类似配置文件，或者宏定义的东西集中的一个头文件里去，看起来很统一也很正规，起码我之前也是这样认为的，但忽然有一天，发现自己这样做显得很不聪明的样子，为什么呢？因为你想想把所有模块配置相关的东西都塞进配置公共文件真的合适吗？是不是把公共接口抽离出来更好，把配置相关的数据下沉到各模块更合适？
另外，把宏都定义到一起，这意味随便改点东西，都会需要修改宏头文件，而这个头文件就会成为程序世界的中心，修改公共宏文件几乎会引起整个系统的所有源文件rebuild，这简直就是AOE团灭啊。所以更好的方式是分而治之，去集中式。
我们知道c/c++的编译单元是source file（.c/.cpp）文件，编译的第一步是预处理，所有include都会展开替换，所以我们要避免引入任何不必要的头文件，也应该把本编译单元用到的头文件都include进来，这就是所谓的头文件自给自足。这点很重要，但很多人会不以为然，甚至有些人会自作聪明的搞一个allincluded.h，把常用的一些头文件全部include进来，然后沾沾自喜的自认为一劳永逸的完美的解决了问题，包含不必要的头文件会增加编译时间，会增加依赖，我们不仅应该避免错误的包含，还应该精心设计和划分文件，使得每个文件的功能足够内聚单一。
累了，意欲未尽，改日再喷！
来源：oschina
链接：https://my.oschina.net/u/4418711/blog/4329402