转载：http://blog.csdn.net/happydeer/article/details/18421417
跟大部分在线社区一样，久而久之，Stack Overflow自然也会趋向于越来越严格。这主要是一种防御机制——类似于小孩在首次进入学校或者托班之后发展起来的一种免疫系统，以抵御来自大千世界的喷嚏、咳嗽（偶尔还有流脑爆发）。这个过程并不总是快乐的，然而，如果你想活下去的话，它又是必需的。
我们来看一看2年前的一个问题吧：
你杜撰过什么编程行话吗？
在编程方面，你杜撰过什么术语吗，并且它在你的圈子里得到了流传（也就是说，你听到别人引用了你创造出来的术语）？它可能只在你的团队里流传，或者在你所在的公司里流传，甚至在整个互联网上都很流行。
把你杜撰的编程术语（单词或短语）用粗体字写下来，然而再解释一下，并附上一个使用的例子，以便于我们了解它的应用场景。
不要重复那些早已在编程文化里妇孺皆知的行话，比如kludge、automagically、cruft等（除非它们真的是你杜撰的）。
本问题秉着增进程序员间相互沟通的精神，让术语在团队和周围环境里得到分享与传播，以使大家都能受益。
这真的是一个问题吗？它最终获得了多少答案呢？386个！
一个问题招来了386个不同的“答案”——这根本已经不是一个问题了。它实际上是一次意见征询或民意测验，抑或是某种清单。我觉得你可能会争辩道，通读所有那些回复可以让你在编程方面有所收获，但我要告诉你的是，其实大量的回复都是些嬉笑和恭维，并没有太多可供学习的东西。这也是为什么这个问题最终被一些资深的社区成员删除的原因。尽管它跟“学习”有点擦边，我个人对删除这件事也没投票赞成，但我还是倾向于同意把它删除。尽管社区里还有不同的意见……
我不想旧事重提（所谓的“娱乐大战”和“赶时髦的麻烦”）。说穿了，Stack Overflow是一所大学，而不是联谊会。网站上的所有内容之所以存在，必须要服务于“快乐学习”这个使命——即使这意味着我们要对那些不符合要求（上下浮动10%）的问题和答案做出艰难的决定去把它们删除。
在程序员文化方面，其实早就有像“The Jargon File”（行话档案）这样的先例。遗憾的是，我们并没有一个特定的地方去收容那些被删除的、“太好玩”的问题。不过，Stack Exchange上的所有内容都是在“创作共用”的框架下永久共享的。这意味着，在适当声明之后，我们可以在我们自己的博客上给那些内容安一个家。于是，我就这么做了。我在这里收集了Stack Overflow上“New Programming Jargon”这个问题的最好的30个回答（它们是由社区评判出来的）。希望你能喜欢！
创作共用（Creative Commons，简称CC）是一个非营利性的组织，也是一种创作的授权方式。这个组织的主要宗旨是，增加创意作品的流通可及性，让一些作品作为其他人据以创作及共享的基础，并寻找适当的法律加以保护。——译者注
简介：1. Yoda Conditions（尤达条件）2. Pokemon Exception Handling（宠物小精灵异常处理）3. Egyptian Brackets（埃及括号）4. Smug Report（自鸣得意的报告）5. A Duck（一只鸭子）6. Refuctoring（重搞）7. Stringly Typed（泛字符串类型）8. Heisenbug（海森bug）10. Jimmy（吉米）11. Higgs-Bugson（希格斯bug）12. Nopping（发呆）13. Unicorny（独角兽似的）14. Baklava Code（千层酥代码）15. Hindenbug（兴登bug）16. Fear Driven Development（恐惧驱动开发）17. Hydra Code（九头蛇代码）18. Common Law Feature（习惯法特性）19. Loch Ness Monster Bug（尼斯湖水怪bug）20. Ninja Comments（忍者注释）21. Smurf Naming Convention（蓝精灵命名规范）22. Protoduction（半成品）23. Rubber Ducking（橡皮鸭）24. Banana Banana Banana（香蕉、香蕉、香蕉）25. Bicrement（加2）26. Reality 101 Failure（现实101失败）27. Mad Girlfriend Bug（野蛮女友bug）28. Megamoth（巨无霸方法）29. HookerCode（妓女代码）30. Jenga Code（积木代码）
1. Yoda Conditions（尤达条件）
尤达是《星球大战》系列中的重要角色。他曾是绝地议会成员，德高望重，也是一位具有强大原力与高尚品格的绝地大师。——译者注
使用if(常量 == 变量)，而不要使用if(变量 == 常量)，比如if(4 == foo)。因为它就像是在说“如果蓝色的是天空”或者“如果高的是男人”。
2. Pokemon Exception Handling（宠物小精灵异常处理）
当你想捕获所有的异常时：
try{
}
catch(Exception ex) {
// Gotcha!
}
3. Egyptian Brackets（埃及括号）
你知道那种开括号放在当前行末尾的括号风格吧？像这样：
if (a == b) {
printf("hello");
}
我们以前常把这种括号风格称为“埃及括号”。为什么呢？把那对括号的位置与上图中那个人的双手比较一下就知道了。（这种括号风格在Kernighan和Ritchie的《C程序设计语言》这本书里得到了采纳，很多人也因此把它称作为K&R风格。）
4. Smug Report（自鸣得意的报告）
指的是一些自以为对系统设计很了解（其实不然）的用户报告的bug。报告里充斥着不相干的技术细节，以及一条或多条建议（常常是错误的），试图指出他所认为的问题的根源，并告诉我们应该怎样去修复。
其他类似的术语还有“Drug Report”（毒品报告，指的是一种完全不可理解的报告，人们有理由怀疑递交报告的人也在吸食毒品）、“Chug Report”（嘎嚓报告，暗指递交报告的人一定喝多了，还在醉意朦胧之中呢）以及“Shrug Report”（耸肩报告，指的是一种不带任何错误信息或重现步骤的bug报告，报告里只有对问题的含糊描述，通常只是简单地说一句“doesn't work”）。
5. A Duck（一只鸭子）
指的是一个功能特性，它存在的意义只是引起管理层的注意、并随后被去掉，以此来避免在产品的其他方面上的不必要改动。
我不确定这个术语是不是真的是由我（这里的“我”指的是kyoryu）发明的，但那个令它传播开来的故事肯定不是我最先讲的。
一开始是这么口口相传的。大家知道，制片人（游戏行业里的一个职位，大致相当于项目经理）必须对做完的东西做一点改动。要不然，他们会在潜意识里认为自己没有贡献。
有这么一个国际象棋的游戏项目。负责为皇后制作动画的美工心里明白上述“潜规则”，于是，他想出了一个好办法。他先按照自己的想法为皇后做了一个精致的动画，然后再附加了一样东西：他为皇后配了一只宠物小鸭。在整个动画过程中，这只鸭子始终与皇后形影不离，总是在角落里拍打着翅膀。他在做这种处理的时候也格外小心，确保了鸭子不会与“真正的”动画重叠。
最后，轮到制片人来审核这个为皇后制作的动画了。制片人先坐了下来，然后观看了所有的动画。看完之后，他转过身面对那个美工，然后说道，“动画看起来棒极了！只是有一点，你得把那只鸭子去掉。”
6. Refuctoring（重搞）
特指这样的过程：一块原本设计得好好的代码，在经过别人反反复复的一系列小改动之后变得完全不可维护。（译者注：这个词源自于Refactoring，即重构。）
7. Stringly Typed（泛字符串类型）
这是对滥用字符串类型的一个讽刺，特指在可以采取对程序员和重构更加友好的实现方式时，却不必要地使用了字符串类型。例如：
- 函数的参数定义为字符串类型，但其实应该使用其他更合适的类型。
- 在一些需要传递字符串的场合下（比如网络服务），字符串在传入函数之后并没有首先转成一个更合适的其他类型——也就是说，先解析字符串，然后创建一个枚举类型，以便后续代码都能使用这种强类型数据——字符串在被调用的函数里从头用到尾。
- 没有使用类型的消息，等等。
过度使用字符串类型常常会使代码难以理解，还会把一些本可以在编译阶段由编译器发现的错误延迟到程序运行时刻才暴露出来。
8. Heisenbug（海森bug）
特指那种当你尝试去研究它的时候突然就消失了或改变了特性的计算机bug。维基百科上的解释是：http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug。
维尔纳·海森堡（Werner Heisenberg）是德国物理学家，量子力学的创始人之一，他也是“哥本哈根学派”的代表性人物。——译者注
9. DoctypeDecoration（文档类型装饰）
特指Web设计师增加了一个doctype声明，却不花心思去写出合法的标记语言程序。
<!DOCTYPE html>
<BLINK>Now on sale!</BLINK>
10. Jimmy（吉米）
泛指没头脑的程序员（或新手）。
这个词是我们在开发一个框架组件时发明出来的，要求是其他开发者在对它的工作原理知之甚少的情况下就能使用它。我们总是在问题中这么措辞：“如果吉米忘记了更新那个属性，会出现什么情况呢？”
这也引出了另外一个术语“Jimmy-proof”，意指设计得很好的框架代码。
11. Higgs-Bugson（希格斯bug）
特指一种假想中的bug。它是根据少量的可能相关的事件日志和传闻中的来自用户的含糊报告推测出来的，但在开发人员的机器上很难重现（如果不是不可能重现的话），因为你其实不知道它是否真的存在，也不知道它是由什么引起的。这个词源自于“Higgs boson”（希格斯玻色子），维基百科上的解释是：http://en.wikipedia.org/wiki/Higgs_boson。
12. Nopping（发呆）
我（这里的“我”指的是Stanislav）正在从人工智能的角度写一部科幻小说，他们的内部语言有很多编程行话。其中，有一个叫“nopping”的术语比较流行。这个词源自于汇编程序里的NOP指令，原指“空操作”。它与“nap”（打盹儿）的拼写也很相近，但又不是“sleep”（睡觉），只是开小差。例句，“Stanislav sat watching the screensaver and nopped for a while.” 意思是，“斯坦尼斯拉夫坐着看屏保，发了一会儿呆。”
13. Unicorny（独角兽似的）
这是一个形容词，用于描述一个尚处于早期计划阶段的功能特性，也暗指有点天马行空。我们是从Yehuda Katz那里剽窃过来的——他在2011年为“Windy City Rails”大会致了闭幕辞，在描述Rails即将推出的一些功能时用到了这个词。
14. Baklava Code（千层酥代码）
特指嵌套了太多层的代码。
千层酥是一种用很多层像纸一样薄的酥皮做成的美味糕点。尽管薄层用在糕点上没什么问题，但用在软件上就价值不大了，尤其是当你有很多这样的层相互叠加在一起的时候，情况就更糟糕了。在你一头扎进代码的时候，每一层都必须被压入大脑的“堆栈”中。（你的脑袋容量够大吗？）此外，层层的酥皮之间是有渗透性的，这样可以让美味扩散。但软件抽象层最好要做到不泄露。当你在软件里一层又一层地叠加时，层与层之间必然是会泄露的！
15. Hindenbug（兴登bug）
特指那种造成灾难性数据损坏的bug。“哦，人性何在啊！”
相关的术语还有“Counterbug”（一种在某人展示这个bug时引起了另一个bug）和“Bloombug”（一种意外生财的bug）。
这个词可能源自于Hindenburg Omen（兴登堡凶兆），它是一种声称可预测美国股市出现股灾的技术分析，由数学家米耶卡（Jim Miekka）于1995年发明。——译者注
16. Fear Driven Development（恐惧驱动开发）
特指项目管理的压力加大的情况（比如，把某人解雇了，将截止日期提前，把一些资源从项目组抽走，等等）。
17. Hydra Code（九头蛇代码）
特指无法修复的代码。就像传说中的九头蛇一样，每个修复都会造成两个新的bug。这种代码应该推倒重写。
18. Common Law Feature（习惯法特性）
特指一种在应用程序里长久存在的bug，大家都已经习以为常，把它当成了正常功能的一部分。如果用户遇到了问题，需要给他们提供支持才能真正解决。
19. Loch Ness Monster Bug（尼斯湖水怪bug）
特指那些无法重现的东西（或者某人只看到过一次的事情）。我听到公司里有很多人都在用这个词。（类似的术语还有“Bugfoot”或“Nessiebug”。）
20. Ninja Comments（忍者注释）
也有人称之为“invisible comments”（看不见的注释）、“secret comments”（秘密的注释）或“no comments”（没有注释）。
21. Smurf Naming Convention（蓝精灵命名规范）
特指几乎每一个类都有相同的前缀。比如说，当用户点击这个按钮的时候，SmurfAccountView把一个SmurfAccountDTO传递给SmurfAccountController。SmurfID用于获取SmurfOrderHistory，然后被传入SmurfHistoryMatch，然后再推给SmurfHistoryReviewView或SmurfHistoryReportingView。如果发生了一个SmurfErrorEvent事件，SmurfErrorLogger会把它记录到${app}/smurf/log/smurf/smurflog.log中。
22. Protoduction（半成品）
这个词是由“prototype”和“production”两个词造出来的，意思是把原型当作正式产品推出了。这个词是从费米实验室的一位技术员那里听来的。据他说，这个词也不是他杜撰的，但他在费米实验室里听别人说过好几次。
23. Rubber Ducking（橡皮鸭）
有时候，你必须把问题说出来。我以前一遇到问题就习惯性地去找我的老板，向他诉说；他只是倾听，没说一句话；我在说问题的过程中自己找到了答案，问题也就解决了。我了解到，有些人会在他们的显示器上放一只橡皮鸭，有问题的时候就对着鸭子诉说。因此，rubberducking就是指把你的问题完整地说出来。
24. Banana Banana Banana（香蕉、香蕉、香蕉）
特指一些占位文本，表示文档正在撰写过程中或者还没写完。常常是因为FxCop（一种静态代码分析工具）抱怨一个公有函数缺少文档说明，于是程序员用这种文字来充数。
/// <summary>
/// banana banana banana
/// </summary>
public CustomerValidationResponse Validate()
其他跟食物相关的术语还有：“Programmer Fuel”（程序员燃料，比如山露汽水、咖啡、马黛茶以及任何能让你精神振奋的东西）、“Hot Potato”（烫手山芋，分别指http和https；音节数量相同，但说起来更好玩）、“Cake”（例句：Marty's noob cake broke the build）和“Chunky Salsa”（主厨莎莎酱，源自于“chunky salsa rule”，特指在正式发布的产品里，一个致命错误或bug导致了整个系统不稳定）。
25. Bicrement（加2）
在一个变量上加2。
26. Reality 101 Failure（现实101失败）
一个程序（或者更可能是程序的某个功能特性）完全按照要求去实现了。但是，当它被投入使用时才知道需求在一开始就被搞错了，所开发的程序基本上也毫无用处。
27. Mad Girlfriend Bug（野蛮女友bug）
当你看到一些奇怪的事情正在发生时，那个软件还告诉你一切正常。
28. Megamoth（巨无霸方法）
这个词代表“MEGA MOnolithic meTHod”（巨大的单一方法）。这种方法（或称函数）常常包含在God Object（上帝对象，指一种知道太多或做太多事情的对象）里，实现代码很长，两屏都显示不完。有人甚至见过超过2000行的方法。要提防啊！
29. HookerCode（妓女代码）
特指有问题的代码，这些代码常常让应用程序不稳定（甚至经常崩溃）。例句，“Did the site go down again? Yeah, Jim must still have some hooker code in there.”（那个网站又宕机了吗？嗯，吉米肯定还有些妓女代码留在程序里。）
30. Jenga Code（积木代码）
特指这样的代码：你改了一小块之后，程序整个儿就崩塌了。
上面这些只是我认为最有可能成为新的编程行话的前30名，而不只是一些纯粹让程序员觉得好玩的东西；当然，这个排名是基于社区投票决定的。要找乐子，就去Reddit.com好了。如果你希望看到更多的，没错，还剩下356个答案你还没看到呢。Stack Overflow的一位老用户Greg Hewgill备份了一些以前被删的问题（http://stackoverflow.hewgill.com），但本文的这个问题似乎还没被他收编呢。如果你等不及的话，你可以试试Stack Printer，或者如果你在Stack Overflow上的声誉值超过了一万的话，你便能看到网站上所有被软删除的问题。