应势而变，构建更加强大的智慧型企业

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

坏的代码，像一个泥团，又或者像一座屎山，阅读的时候，你仿佛被困于黑暗的迷宫，又仿佛在跟一个絮絮叨叨的人交谈，她的脑回路经常短路，说话含混不清，主次不分，叨逼半天，你依然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 XX标准的安全做法，全然忘记你在编写的是一个私有实现函数，你在调用它之前已经检查过一遍，私有函数是一个受控的安全上下文，这不仅不优雅而且不绿色(低效耗电)并且不安全(在该崩的时候没崩把雷埋到了更隐蔽的地方)，话说你看标准库函数strcpy/strcat，vector operator[]检查传参了吗?

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

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

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

封装

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

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

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

解耦

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

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



 

（编辑：南通站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!