编程行业里面的新行话
轉載：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上的聲譽值超過了一萬的話，你便能看到網站上所有被軟刪除的問題。
總結
以上是生活随笔為你收集整理的编程行业里面的新行话的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 涨乐财富通app怎么调出筹码
- 下一篇： Ruby. Vs . Python