首先，糟糕的程式碼不僅影響程式設計師的心情，更會直接影響專案開發進度，嚴重的會影響整個開發團隊的氛圍。

對於程式設計師來說，遇到糟糕的程式碼大部分是兩種情況，一種情況是半路接手別人的程式碼，另一種情況是團隊成員提交的程式碼，無論是哪一種情況，糟糕的程式碼都會影響整體的開發進度。

對於程式設計師來說，半路接手別人的專案程式碼幾乎是不可避免的事情，因為程式設計師的角色轉換通常都會比較頻繁。半路接手別人程式碼的時候就有可能會遇到比較糟糕的程式碼，尤其是接手初級程式設計師編寫的程式碼。

我曾經就多次接手過別人開發一半的程式碼，其中大部分程式碼都是非常規範的，而且思路非常清晰，整理起來也非常容易，但是也遇到過不那麼規範的程式碼，比如整篇程式碼沒有添加註釋，模組劃分比較隨意等等。遇到這樣並不規範的程式碼，首先就要花費較長的時間才能理清開發思路，然後新增必要的註解，自然就會浪費不少時間。

我在跟別的軟體團隊進行合作開發的時候曾經遇到過比較糟糕的程式碼，當時我們多個團隊協作開發一個大型的專案（智慧城市類），其中有個程式設計師提交的程式碼總是出現各種各樣的問題，每次都會浪費不少時間，當時整個開發團隊的心情都比較糟糕，因為連續的加班已經讓大家比較疲憊了，結果因為一個程式設計師的原因，我們都需要反覆配合測試，這種情況會嚴重影響整個開發團隊的工作氛圍，最終經過討論把這名程式設計師調離了專案組。

目前，隨著軟體開發流程的逐漸規範化，糟糕的程式碼已經非常少了，相信未來程式設計師的程式碼會越來越規範。

自己曾經閱讀過別人寫的程式碼，不規範之處舉例如下：

（1）沒有註釋，不知道有些自定義方法什麼意思。

（2）方法命名拼音和應用相結合，有些還帶著數字，比如create和create1和createe的區別。

（3）很長很長一段程式碼，有些引數是寫死的，完全不能複用。

（4）一段堆一起的程式碼，找到寫程式碼的人，他自己都忘了具體的實現邏輯了。

（5）能用10行程式碼實現的東西，你寫了好幾百行，是什麼意思？

（6）執行報錯的程式碼，還得幫人除錯改程式碼

……

心情很複雜，用一張圖來表達心情：有種別跑，看老子不打死你！