经调查发现，当程序员看到这些奥妙无穷、灵气逼人、独具巧思的好代码时，血压便会急速上升，一边在内心啧啧感叹，嘴上也得说上两句甜蜜而亲切的话语。或可被用于治疗低血压。
Top 10 “沉默的羔羊” && “唐僧崇拜者”
“沉默的羔羊”是一群固执的信徒，他们坚守着一项古老的传统——不写注释！他们是实用主义者，通常认为有写注释的时间，还不如多摸会儿鱼，哦不，多写几行业务代码。但是当他人不写注释时，“沉默的羔羊”便一反常态的使用“双标”技能进行谴责，或许在他们看来，不写注释是只有高贵信徒才可以做的事情，凡人可不能学哦。
“唐僧崇拜者”则是另一个极端，是“沉默的羔羊”的反对派，他们极其酷爱写注释，并且认为注释越多越好。他们会为代码写一串长长的注释，用于解释代码运行所需的一切，但如果去掉注释，代码便极难看懂，不过没关系，代码看不懂？有注释呀！你看注释！
“沉默的羔羊”&&“唐僧崇拜者”本是一体两面，本质上都是对那些可以自解释的代码的蔑视，他们不认为代码可以有准确的命名与易懂的实现，于是一个选择破罐破摔，一个则选择用补丁堵住千疮百孔。所以两者并列 Top10。
Top 9 “暗影刺客”
“暗影刺客”神出鬼没，分布在代码的各个角落，他们都有相似之处，但不全然相同。当程序员需要进行某些修改时，必须找出每个“暗影刺客”进行改动，否则可能会导致bug。如果一个需求需要修改的代码散步在各处，程序员不但很难找到他们，也很可能错过某个重要的修改。这就是他厉害的地方。
悄悄告诉你：有些程序员会使用“聚合代码”，将需要修改的代码汇聚到一处，写在一个方法或函数里，这样便可将修改处一并解决掉。
Top 8 “混乱法师”
“混乱法师”掌握着一项神奇的技能，称为“魔法数字”，用起来很简单，就像这样：
func GetGenderCoin(gender int) string {
var coin string
switch gender {
case 1:
coin = 6
case 2:
coin = 5
default:
coin = 5
}
return coin
}
func GetCoinByGender(coin string) int {
var gender int
switch coin {
case 6:
gender = 1
case 5:
gender = 2
default:
gender = 2
}
return gender
}
这是一份很简单的示例，你或许可以猜出 case 1 和 case 2 分别是什么意思？好吧，不可能猜的出来。那么加上注释：
func GetGenderCoin(gender int) string {
// 女性返回 6 coin，男性或其他返回 5 coin
// 1：女性，2：男性
……
}
func GetCoinByGender(coin string) int {
// 6 coin返回女性，5 coin或其他返回男性
……
}
在代码中，分别用了几个神秘的数字以标识 gender 和 coin 的类型，但不看注释的话极难理解。
这样的代码对于低血压人群来说是非常有帮助的。
悄悄告诉你：可以把“魔法数字”分别用常量或方法封装起来，在需要时直接调用常量或方法即可。
Top 7 “参数之炼金术师”
“参数之炼金术师”擅长将一大串稀奇古怪的参数统统传入一个函数，然后在函数中架起一口大锅，把参数一一扔进去，最终将制成品return出来。就像这样：
func alchemical(animals, flowers, eyes, nose, kangaroo, lightning, stone, hair string) int {
……
}
悄悄告诉你：过长的参数列表常会令人迷惑，当遇到这种情况可以考虑直接传入一个数据结构哦。
Top 6 “代码巨魔”
“代码巨魔”诞生于上古时代，并一直延续至今。程序员们通常都知道“代码越长，越难理解”的道理，但“代码巨魔”却坚持己见，他们创造出的一个个动辄上千行的函数，是如此巨大，让人闻之瑟瑟发抖。
悄悄告诉你：面对“代码巨魔”，我们可以先通读一遍函数，理清思路，然后着手“重构”，将其切分成小的模块。
Top 5 “恶趣味的天才”
天才很迷人，但“恶趣味的天才”是否迷人呢？“恶趣味的天才”总是会写一些“聪明的”代码，明明可以用更易懂的方式表达，但他们偏不。
就像这行代码，普通人难以看懂：
const record = isOK > isVip ? "ok?" : isVip > isTime ? "vip!" : null;
悄悄告诉你：设计程序时一定要考虑怎样做能达到最小复杂度，设计的首要目标就是要让复杂度变小，要避免做出“聪明的”设计，因为“聪明的”设计常常都是难以理解的。
Top 4 “命名学家”
“命名学家”的命名功力深不可测，他们精通各种命名方法，比如下面这些：
// 脸滚键盘式命名
dsadasj := "脸滚键盘式命名"
// 中文拼音式命名
zhonwenpinyin := "中文拼音式命名"
// 极简主义式命名
t := "极简主义式命名"
// 丑陋不堪式命名
nOtvIP := "丑陋不堪式命名"
// 全部大写式命名
NOTVIP := "全部大写式命名"
有些程序员会深思熟虑的给函数与变量命名，最终使得其命名可以清晰的解释出对应的功能与用法。而“命名学家”则不屑一顾。
悄悄告诉你：如果一个命名不能表明其功能，则命名无意义，除非是用过就丢的那种变量（比如这种 for var i=1; i < 5; i++）。如果命名足够好，甚至不需要注释就能看懂一段代码的含义。
Top 3 “来自嵌套地狱的使者”
“来自嵌套地狱的使者”带来了一页代码，让我们看一下：
ok，硬了，拳头硬了。
Top 2 “恐怖天使”
“恐怖天使”又被称为“全局变量”或“可变数据”，她像天使一样照顾着项目里每一处可以引用到她的地方，但她不是常量，一旦被修改，她就变身恐怖天使，令人闻之颤抖。
对数据的修改经常导致出乎意料的的结果和难以发现的bug。我在一处更新数据，却没有意识到软件中的另一处期望着完全不同的数据，于是一个功能就失效了，而且找出故障的原因也会非常困难。
悄悄告诉你：可以将“可变数据”封装起来，写一个查询方法专门用来获取这些值。
Top 1 “上古之神的低语”
“上古之神的低语”渊源流长，他是一整套巨大的代码集合，在这其中有许许多多程序员参与其中，交付于多人之手，程序员来来去去，最终形成一个令人闻风丧胆的项目。
通常，在这种项目中会聚集 Top 10 - Top 1 的各路好汉，八仙过海，各显神通。听说曾经有一个同事抱怨一个项目的一处代码太烂，一查提交记录，好家伙，他自己写的；听说曾有人修改过这个项目的一处代码，好家伙，一测试，八竿子打不着的地方出bug了。
像这种巨石一般的项目已经不是一个人单枪匹马能解决的了，要么重开，要么只能投入精力重构。
做程序员几年来，多多少少也见过了一些“好的代码”，遂至年末，便想要拿出来评选一番。这些代码都是日常遇到过的“好东西”，如果还有遗珠的话，也只能怪作者见识不够广博，还请谅解。至于排名，权当作笑料便可。
