這些事兒我們都乾過：比如趁媽媽不注意趕緊偷吃一塊餅乾；比如開車過急轉彎不減速。當然，編程的時候我們也愛來點小叛逆。
我們對好的編程規則不屑一顧，打出來的代碼非常糟糕——可也就這麼對付過去了，並沒有編程之神用閃電懲罰我，我們的電腦也沒有爆炸。實際上，我們的代碼已編譯完成並交付使用，客戶也似乎很滿意。
那是因為糟糕的代碼並不像摸電門或者摸老虎屁股那樣後果嚴重，大多數時候這些代碼都能用。編程規則往往只是指引或對編程風格的建議，並不會出現不遵守代碼就會完蛋的鐵律。當然，你的代碼可能會被同行嘲笑，甚至是“公開處刑“。但違反約定也是一種有點刺激的反叛行為；這種叛逆行為往往是產生優秀代碼的一種途徑，哪怕你不是故意為之。
讓事情變得更複雜的是，有時打破規則才是更好的選擇。這樣的代碼沒準兒會更清晰，甚至可以更快更簡潔。規則往往太過寬泛，熟練的程序員可以為了改進代碼而打破常規。有時候用自己的方式編程是很有意義的，不過這一條可別跟你的老闆說。
下面是10條規則列表，其中也有被認為是不可逾越的規則，但我們很多人經常會打破這些規則，而且結果還很不錯。
TOP1：粘貼複製
在學生時代，我們都知道抄襲是不對的。但在工作中，這方面的規則還很模糊。雖然有些代碼塊是不能盜用的——不要把專有代碼拷貝到你的堆棧中，尤其是這些代碼有標記版權信息。這種時候你應該編寫自己的版本，老闆付你薪水就是要做正事的。
但是當原始創作者想要共享代碼時，問題就變得複雜了。這些共享代碼也許放到了某個在線編程論壇上，也許它們是帶有許可證（BSD，MIT）的開放源代碼，允許使用一到三個函數。你使用這些共享代碼是沒有問題的，而且你上班是為了解決問題，而不是重新發明輪子。
大多數情況下，複製代碼的優勢非常明顯，小心對待的話問題也不大。至少那些從靠譜的來源獲得的代碼已經被大致“檢查“過了。
問題的複雜之處在於，這些共享代碼是否存在一些未發現的錯誤，代碼的用途或底層數據是否存在一些特別的假設。也許你的代碼混入了空指針，而原始代碼從未檢查過。如果你能解決這些問題，那麼就可以理解為你的老闆得到了兩位程序員共同努力的成果。這就是某種形式的結對編程，而且用不著什麼高大上的辦公桌。…
