因為趕時間，或者是不太注重程式設計代碼的效果，不少人隻注重實作程式基本功能，而忽略程式設計規範，結果是寫的代碼很難讀懂，甚至連閱讀自己的代碼都十分困難，這造成時間浪費，做事效率降低。關鍵是為老師和杜代碼的同學造成一定的困難，進而造成交流上的困難！
“首先是為人編寫程式，其次才是計算機”，這是軟體開發的基本要點，軟體的生命在于的是互相溝通與交流，而交流的前提是有一定的規範！隻有易讀、易維護的軟體代碼才具有生命力。
如果不為人程式設計，帶來的後果是？
進度是趕上了，産品也傳遞出去了，一切看來是OK的，但問題也就來了。前方産品故障頻發，後方開發人員不停地撲火。這個時候，他們才發現之前别人寫的代碼很難讀懂，甚至連閱讀自己寫的代碼都十分的困難，真是悔不當初。如果開始的時候能夠将代碼寫規範一點，文檔配備齊全一點，何至于此？
“好”的代碼和“不好”的代碼給人的感覺是千差萬别。當我們看到優美的代碼時，會有一種想繼續研究下去的欲望，甚至會有一種覺得很享受的感覺。相反，當我們看到醜陋的代碼時，就會咬牙切齒，因為它不僅不利于閱讀，還會浪費我們很多時間，降低我們做事的效率。
排版工整 VS 排版不工整
我們打開一個代碼檔案的時候，最先看到的就是其排版怎樣，這也是最直覺的感覺。當代碼排版工整時，我們很容易找出其條理和邏輯，會很快了解其到底要實作什麼功能；而排版不工整的時候，我們的眼睛會覺得很累，進而影響了我們的思維。
命名規範 VS 命名不規範
在看完排版之後，我們就會看到每個函數和變量的命名。由于一般項目的代碼行數都比較多，我們不可能花很多時間去了解每個函數和變量到底是何用意，到底是拿來做什麼的。這就要求我們在編碼的時候，使函數和變量的命名具有自說明性，讓它們自己告訴讀者是做什麼用的，而不是要别人花大量時間去研讀後才能知道。這在一定程度上反映了開發人員的态度和專業化程度。
注釋得當 VS 注釋不得當
閱讀代碼，我們還會注意到其是否有注釋，注釋多還是少。這也是很直覺的。
如果代碼實作的功能較為複雜，那麼添加注釋是必不可少的。在恰當的地方，使用恰當的注釋，能夠讓讀者覺得思路豁然開朗，他們會默默地在心裡感激你。
為人程式設計：如何才能寫出讓“人”看得懂的好代碼
有些人認為：我擅長制定編碼規範，你們聽我的就好了。我覺得這樣是很不可取的！我們不應該有這種獨裁主義精神，技術追重要的就是交流！