這些事兒我們都幹過：比如趁媽媽不注意趕緊偷喫一塊餅乾；比如開車過急轉彎不減速。那麼，編程的時候我們也會有哪些“壞習慣”？
不良的編程習慣TOP1：粘貼複製
在學生時代，我們都知道抄襲是不對的。但在工作中，這方面的規則還很模糊。雖然有些代碼塊是不能盜用的——不要把專有代碼拷貝到你的堆棧中，尤其是這些代碼有標記版權信息。這種時候你應該編寫自己的版本，老闆付你薪水就是要做正事的。
但是當原始創作者想要共享代碼時，問題就變得複雜了。這些共享代碼也許放到了某個在線編程論壇上，也許它們是帶有許可證（BSD，MIT）的開放源代碼，允許使用一到三個函數。你使用這些共享代碼是沒有問題的，而且你上班是爲了解決問題，而不是重新發明輪子。
大多數情況下，複製代碼的優勢非常明顯，小心對待的話問題也不大。至少那些從靠譜的來源獲得的代碼已經被大致“檢查“過了。
問題的複雜之處在於，這些共享代碼是否存在一些未發現的錯誤，代碼的用途或底層數據是否存在一些特別的假設。也許你的代碼混入了空指針，而原始代碼從未檢查過。如果你能解決這些問題，那麼就可以理解爲你的老闆得到了兩位程序員共同努力的成果。這就是某種形式的結對編程，而且用不着什麼高大上的辦公桌。
不良的編程習慣TOP2：非函數式代碼
在過去十年間，函數範式愈加流行。喜歡用嵌套函數調用來構建程序的人們引用了很多研究成果。這些研究表明，與舊式的變量和循環相比，函數式編程代碼更安全，錯誤更少，而且可以隨程序員的喜好任意組合在一起。粉絲們十分追捧函數式編程，還會在代碼審查和拉取請求中詆譭非函數式方法。關於這種方法的優勢，他們的觀點其實並沒有錯。
但有時你需要的僅僅是一卷膠帶而已。精心設計並細心計劃的代碼需要花費很多時間，不僅需要花費時間想象，還需要構建和之後導航的時間。這些都增加了複雜性，並且會花費很多的時間與精力。開發漂亮的函數式代碼需要提前做計劃，還要確保所有數據都通過正確的途徑傳遞。有時找出並更改變量會簡單得多，可能再加個註釋說明一下就夠了。就算要在註釋中爲之後的程序員致以冗長而難懂的歉意，也比重新設計整個系統，把它扳回正軌上要省事得多。
