能很多朋友都看過一部名叫《一只名叫Bob的流浪貓》的電影，

這個電影在2017年獲得了很多國際大獎，全世界范圍的網友都為James和Bob之間的感人友誼而感動到落淚。

這部電影其實是根據英國一個名叫James Bowen的流浪漢的親身經歷寫成的小說而改編而成的。

迄今為止，James已經出了8本和流浪貓Bob有關的書，并且在全世界范圍內被翻譯了超過40種語言，銷售量高達900萬冊。

James現在的身份是一個樂隊的主唱，著名音樂人和暢銷書作家，

然而他在十幾年前的時候，根本不會想到自己的一生將會被一只突如其來的姜黃色流浪貓所改變。

2007年的春天，James還是一個被家人遺棄、流浪街頭，依靠唱歌賣藝乞討謀生，并且染上毒癮的問題青年。

當時他沒有地方可以去，只能住在政府給他臨時安排的，位于倫敦北部托特納姆區的一個狹小的一居室解困房公寓里。

一天，一只受傷的流浪貓，出現在他公寓外的走廊上。

他等了半天都沒有找到這只受傷流浪貓的主人，于是只好花光了身上最后的30英鎊，帶這只流浪貓去獸醫那里治療它受傷的腿。

如果沒有這只貓的突然出現，他的生活永遠都不會有轉機。

“因為這只貓的出現，讓我意識到自己要對身邊的這個小生物負責任，它需要我來照顧。

也從那時候開始，我的生活中開始出現了一些積極的事情，Bob對我的生活影響非凡，他是我最好的朋友。”

把Bob的傷養好了之后，James就開始帶著它一起生活。

Bob是一只非常通人性的貓，它總會蜷縮在James的肩膀上一動不動，James帶著Bob去倫敦的考文垂花園唱歌賣藝，

因為這只萌萌的小貓的出現也讓James的賣藝生涯變得好過了許多，很多游客紛紛駐足圍觀，拍照留念，所以James賣藝的收入，也開始成倍的增長。

那段時間，James正在經歷人生中最難熬的戒毒期，當他進行到戒毒關鍵階段的時候，必須要停止服用任何幫助戒毒的鎮靜藥物。

而在那最難熬的一段時間里，James把自己鎖在家里，大門緊閉，一個人痛苦的熬過了這段時光，身邊只有這只流浪貓的陪伴。

幸好，他熬過來了，他獲得了新生。

因為有了Bob的陪伴，James對人生變得更加積極樂觀了。

Bob非常可愛，而且還會站起來和人擊掌，所以James的人緣也變得越來越好，他把自己和Bob在一起生活的經歷寫成了書，沒想到一下子就獲得了全世界范圍讀者的歡迎。

現如今的James已經不用再為了生計發愁，他用稿費賺來的錢給自己投資了一套房產，和Bob幸福的生活在了一起。

就在這個月初的時候，他還和自己的女朋友浪漫地舉行了求婚儀式。James在給女友的求婚戒指的背面刻制了她的昵稱：“我的小貓”。

James的女友Monica今年36歲，來自波蘭，兩個人都非常喜歡養貓，也都很喜歡音樂，他們是通過共同好友在Facebook上互相認識的。

Monica之前對于James的經歷并不是十分了解，她甚至沒有看過James寫的書和他的書改編成的電影，直到兩個人認識之后，她才開始閱讀James的經歷。

“在讀到他以前沒有人陪伴，必須要依靠海洛因來支撐自己破碎的生活的時候，我感覺非常心疼，他和Bob之間的感情非常特別，而我也非常開心能夠成為他們生活中的一部分”Monica說。

有趣的是，James說之前雖然也有過很多女生主動聯系他、發出邀約，但是Bob都沒有同意。而這一次當Monica第一次來到James的家中的時候，Bob就表現出了非常溫順和歡迎的態度！

“我第一次到James家的時候，Bob就主動上來吻我，用頭蹭我，還允許我把它抱起來。”Monica說。

現在由于James和Monica已經戀愛很久了，Bob甚至對Monica還會更親密一些，

每天早上當它想要吃早餐的時候，Bob首先都會去找到Monica，跳到她的枕頭上，蹭著她的臉，直到她起床給它準備貓糧。

Monica自己也養了一只名叫Pom Pom的小母貓，它和Bob成為了朋友。

“Pom Pom是我朋友家的貓生下的6只小貓中的一只，當它第一次和Bob見面的時候，它們先是花了一點時間來了解彼此，然后很快就開始在房子里一起玩耍奔跑，蜷縮在一起睡覺，他們真的非常相愛。”

對于Bob來說，他的生活似乎是完美的。它有自己的寵物護照，和James一起環游世界，曾經造訪過巴黎、奧斯陸、柏林、阿姆斯特丹和里斯本等城市。

家中墻上的一張照片顯示，Bob站在東京麗思卡爾頓酒店50層套房的窗前，凝視著窗外城市的景色。

“它喜歡旅行，不管是坐飛機、火車還是汽車都超開心“James說。

但它在家里也同樣快樂，和James、Monica一起窩在床上，啃著它最狂熱的粉絲們寄給它的貓糧，還有它最喜歡的小白鼠玩具，或者蜷縮在Pom Pom的懷里……

雖然Pom Pom只有6歲，但是根據推測，Bob的年齡應該已經在14到15歲之間--如果按照貓的年齡推算，它應該已經相當于人類的70多歲了。

它的晚年是James一直不愿細想的現實，不過James覺得，Pom Pom和她們最近剛收養的一只小貓，或許是Bob在冥冥之中留給自己的禮物。

James和Monica計劃在明年舉行婚禮，他們的生活將會展開新的篇章，希望他們可以一直幸福快樂的生活下去。

ref:

https://www.dailymail.co.uk/news/article-7287381/Bob-cat-helps-owner-James-Bowen-love.html

脫這些壞習慣可以帶來意想不到的效果：編寫出更優質精簡的代碼。

以下為譯文：

我們都有過這樣的經歷：在媽媽不注意的時候偷吃一塊餅干；聚餐時過量飲酒；把車停在超時停車的停車位上——我們甚至在死亡邊緣瘋狂試探。是的，我們違反了許多編程的基本規則，那些大家都認為是不好的規則，而我們卻偷偷地使用著。

我們對好的編程規則嗤之以鼻，輸出的代碼也一塌糊涂——但我們做出來了。沒有來自編程之神的五雷轟頂，我們的桌面也沒有爆炸。事實上，只要我們的代碼可以編譯并交付，客戶似乎就很滿意了。

這是因為糟糕的編程不像安裝電路或者摸老虎屁股那樣有直接的危害性。大多數情況下，它也是可以運行的。規則通常是作為一種指導或格式上的建議，并沒有硬性規定一定要遵守，也不會導致代碼出現問題。當然，你的代碼可能會被人恥笑，甚至可能大家公開嘲笑你。不過，這種挑戰慣例的行為可以讓人增加一點顛覆傳統的快感，哪怕是在不經意間。

讓事情變得更復雜的是，有時候違反規則反而更 好。（噓！）輸出的代碼會更干凈，甚至可能會更快更簡單。規則通常顯得太過于寬泛，有技巧的程序員可以通過打破這些規則來優化代碼。不要告訴你的老板，這對你的編碼生涯會很有意義。

下面這十條編碼習慣常常是被駁斥的，但我們很多人就是會不由自主地使用它們，覺得好用且實用。

編程壞習慣一：拷貝

在學校里，拷貝是不對的。而在工作中，規則不是很明確。當然有一些代碼塊不應該被竊取。如果它來自私有代碼，不要將它拷貝到你的堆棧中，特別是標記了版權信息的。請編寫自己的版本，這是有報酬的。

更棘手的問題出現在原創者想要分享的時候。可能是在一個在線編程論壇上；也可能是具有許可證的開放源代碼（BSD、MIT），它允許竊取其中一到三個函數。你無需承擔法律責任。你的工作是解決問題，而不是重新發明輪子。

大多數情況下，拷貝的優點是不可抗拒的，而缺點可以稍加限制。從一個可靠來源處獲得的代碼已經至少經過一輪思考與實踐。最初的作者尋找解決方案并找到新思路，給出了循環不變量和數據流。

拷貝的棘手問題是，是否存在一些未發現的bug，或者關于角色或底層數據的一些不同假設。也許你的代碼混合了空指針，而原始代碼卻從未檢查出來。如果你能解決這些問題，就好比你的老板能從兩個程序員那里得到輸入一樣。這是結對編程，沒有華麗的鋪陳。

編程壞習慣二：非功能性代碼

在過去的十余年里，功能范式一直在提升。研究表明，在調用嵌套函數的基礎上構建程序，代碼會比老式的變量和循環更安全、更少bug，所有這些都足以使程序員滿意。狂熱者義憤填膺地譴責代碼審查和拉取請求中的非功能性請求。這可能是真正的優勢。

但有時你只需要復制粘貼。精心設計和優雅規劃的代碼不僅需要時間來想象，還需要時間來構建和導航。所有這些層都增加了復雜性，而復雜性就是金錢。寫出漂亮函數代碼的開發人員需要提前規劃，并確保所有數據都沿著正確的路徑傳遞。有時候改變一個變量更容易，這也許可以寫個評論來解釋一下。即使在評論中向未來幾代人注上一長串真誠的道歉，也比以正確的方式來重構整個系統要快得多。

編程壞習慣三：不標準的間距

軟件中的大多數空格對程序的執行沒有影響。除了像Python等少數使用空格表示代碼塊的語言外，大多數空格對程序的行為沒有影響。盡管如此，仍有一些執迷于此的程序員，他們計空格數并堅持認為這很重要。曾有人義正言辭的向我老板控訴我在寫“非標準代碼”，且他一眼就看出來了。我的錯咯？沒有在等號兩邊都加上空格，違反了ESLint space-infix-ops規則。

有時你必須考慮比空間位置更深層次的東西。或許你擔心數據庫超載，又或許你擔心一個空指針會使你的代碼崩潰。幾乎代碼的任一部分都比空格更重要，即使挑剔專橫的標準委員會已經制定了諸多關于空格或制表符位置的規則。

令人驚奇的是，有幾個很好的工具可以自動地重新格式化代碼，以遵循任何規定的linting規則。我們不需要花時間去思考這個問題，如果它如此重要，我們可以通過運行工具來清理問題。

編程壞習慣四：使用goto

禁止使用goto可以追溯到許多結構化編程工具尚未面世的時代。如果程序員想創建一個循環或跳轉到另一個程序中，他們需要輸入GOTO再在后面加上一個行號。幾年后，編譯器團隊允許程序員使用字符串標簽而不是行號。這在當時被認為是一個熱門的新功能。

有些人認為這會導致“意大利面式的代碼”。代碼會變得不可讀，并且很難理解代碼的執行路徑。那是一團亂麻，永遠纏繞在一起。Edsger Dijkstra用一篇名為“Goto語言害人不淺”的滑稽手稿建議禁止goto命令。

但絕對分支是沒有問題的。這就讓人糾結了。通常，巧妙的break或return將提供一個非常清晰的聲明，說明代碼在該位置正在做什么。有時候，將goto添加到case語句中會更容易，而不是一組結構更合理的層疊if-then-else塊。

也有反例，蘋果SSL協議棧中的“goto fail”安全漏洞就是最好的例子之一。但是，如果我們小心避免case語句和循環的一些棘手問題，我們可以插入良好的絕對跳轉，讓讀者更容易理解。我們可以插入一個break或return，這對每個人來說都更干凈簡明——可能除了那些goto厭惡者。

編程壞習慣五：沒有聲明類型

那些熱愛類型化語言的人認為，如果為每個變量添加明確的數據類型聲明，就可以寫出更好、沒有bug的代碼。在代碼運行前，花一段時間來拼寫出類型，可以幫助編譯器標記出愚蠢的錯誤。這可能不容易做到，但它是有幫助的。這是編程中阻止bug的一種有備無患的方法。

但是時代變了。許多較新的編譯器足夠智能，可以通過查看代碼來推斷類型。它們會前后反復的查看代碼，直到確定變量是string,int或其他類型。如果這些推斷的類型不成隊列，那么編譯器就會拋出一個錯誤標志。因此就不再需要我們輸入變量了。

這意味著現在可以通過省略一些最簡單的聲明來簡化代碼。代碼變得更簡潔了，而且讀者通常能夠猜到在for循環中名為i的變量是一個整數。

編程壞習慣六：溜溜球代碼

程序員喜歡稱之為“溜溜球代碼”。一開始先將值存儲為字符串，然后又解析成整數，接著又轉換回字符串。這是非常低效的。你幾乎可以感覺到CPU在所有額外負載下的掙扎。聰明的程序員之所以能快速的編碼，是因為他們事先會設計架構，以盡量減少轉換。因為他們的良好規劃而使得代碼更快的運行。

但是不管你信不信，有時候這種溜溜球代碼是有道理的。比如你有一個很棒的庫，在其專有的黑盒子里能做無數智能的事情。又比如，老板會開一張七位數的支票，賦予黑盒子所有杰出功能。如果庫需要字符串形式的數據，那你就給它字符串，即使你剛將其轉換為整數。

當然，你也可以重寫所有代碼以盡量減少轉換，但這需要時間。有時，代碼多運行一分鐘、一小時、一天甚至一周都沒有問題，因為重寫代碼會花費更多的時間。有時候，積累技術債務比一開始就把它建好要便宜。

有時，這個庫不是私有代碼，而是你很久以前自己編寫的代碼。有時，將數據轉換一次比重寫庫中的所有內容更快。所以，就繼續寫溜溜球代碼吧，沒關系的，我們都經歷過。

編程壞習慣七：編寫自己的數據結構

其中一個標準規則是，程序員在大二時修完數據結構課程后，絕不應該編寫用于存儲數據的代碼。其他人已經編寫了我們需要的所有數據結構，他們的代碼經過了多年的測試和重新測試。它與語言捆綁在一起，而且可能是免費的。而你寫的代碼可能只有bug。

但有的時候，你會發現數據結構庫有點慢。有時它們迫使我們進入一個可能是標準的但對我們的代碼來說是錯誤的結構。有時，在使用結構之前，庫會要求我們重新配置數據。有時庫包含一些所謂有備無患的保護功能，而我們的代碼不需要它們。

如果遇到這種情況時，我們就該編寫自己的數據結構了。這可能會更快更好。有時它使我們的代碼更簡潔，因為我們沒有包含所有額外的代碼來精確地重新格式化數據。

編程壞習慣八：老式的循環

很久以前，有人創建了C語言，希望將所有抽象的可能性封裝在一個簡單的結構中。某些事情在開始時就要做，某些在每次循環時要做，還有一些方法可以告訴你什么時候完成。當時，它似乎是一種捕捉無限可能性的完美語法。

然后，現在一些現代的責罵者只看到其不便性。太繁瑣了。所有這些好的可能性也同樣可能是壞的。這使得閱讀和拓展變得更加困難。他們喜歡功能范型，沒有循環，只有應用于列表的函數，計算模板映射到一些數據。

有時，無查找方式更簡潔，特別是只有一個整潔的函數和一個數組時。但有時老式的循環要簡單得多，因為它可以做更多的事情。例如，如果您可以在找到第一個匹配項時立即停止，那么搜索它就會變得更簡單。

此外，當需要對數據執行多個操作時，映射函數會鼓勵更草率的編碼。假設你想取絕對值然后取每個數的平方根。最快的解決方案是映射第一個函數，然后映射第二個函數，對數據進行兩次循環。

編程壞習慣九：中途跳出循環

規則制定小組宣稱，在代碼行中的某個地方，每個循環都應該有一個“常量”，即在整個循環中邏輯語句為真。當該常量不再為真時，循環結束。這是考慮復雜循環的一種好方法，但它會導致愚蠢的禁令——比如禁止我們在循環中間使用return或break。這也包含在禁止goto語句規則中。

這個理論很好，但是它通常會導致更復雜的代碼。考慮這種簡單的情況，遍歷數組，將找到的元素傳給test函數，并將該元素返回：

while (i<a.length){ ...if (test(a[i]) thenreturn a[i]; ...}

循環常量愛好者會要求我們添加另一個布爾變量，命名為notFound，然后這樣使用：

while ((notFound) && (i<a.length){ ...if (test(a[i])) then notFound=false; ...}

如果這個布爾值命名正確，它就是一段很好的自文檔化代碼，更易于大家理解。但它也增加了復雜性。它還意味著分配另一個局部變量并阻塞寄存器，而編譯器可能不夠智能，無法修復這些問題。

有時，一個goto語句或一個跳轉會更干凈利索。

編程壞習慣十：重新定義運算符和函數

一些最有趣的語言可以讓你做一些尤為曲折的事情，比如重新定義看起來應該是常量的元素的值。例如，Python允許輸入TRUE=FALSE，至少在2.7版之前是這樣的。這并沒有造成某種邏輯的崩潰和宇宙的終結;它只是交換了TRUE與FALSE的意義。你也可以用C預處理器和其他一些語言玩類似的危險游戲。還有一些語言允許你重新定義運算符，比如加號。

這是一種延伸，但是當要更快速的重新定義一個或多個所謂的常量時，其在代碼塊中意義非凡。有時候，老板希望代碼做一些完全不同的事情。當然，你可以遍歷代碼并更改每個事件，或者重新定義。它會讓你看起來像個天才。不需要重寫一個龐大的庫，只需稍微翻轉一下，它就會執行相反的操作。

也許在這里劃清界限比較好。你不應該在家里嘗試做這個，不管它有多聰明和有趣。這太危險了——真的......

想要在程序員生涯內有更高的成就的話，最最重要的是盡可能的提升自己的編程能力，并且，與其想著怎么去提升，不如從現在開始動手動腦，如果對于C/C++感興趣的話，可以關注+私信小編【C/C++編程】有一些視頻希望可以幫助到你，學習不怕從零開始，就怕從不開始。

作者 | Peter Wayner

譯者 | 譚開朗，責編 | 郭芮

原文：https://www.infoworld.com/article/2992566/10-bad-programming-habits-we-secretly-love.html