人跟人的能力千差萬別，所以寫出來的代碼質量，肯定是不同的。有的人，寫一個小邏輯，可能需要100行，而有的人，可能僅僅需要10行。代碼永遠會有Bug，在這方面沒有最好只有更好。模塊化與面向對象是實現高效無錯代碼的方法。高效無錯代碼需要思想與實踐的不斷反復。如何做到代碼高效無錯，提高代碼質量的方法有哪些？又有哪些經驗和技巧呢？
一、代碼質量
軟件是交付給用戶，並由用戶體驗的產品；代碼則是對軟件正確且詳細的描述，所以代碼質量關系到軟件產品的質量。雖然軟件質量不等於代碼質量，但是代碼上的缺陷會嚴重的影響到軟件產品的質量。因此，為提高代碼質量的投入是值得的。
二、軟件產品質量通常可以從以下六個方面去衡量
功能性，即軟件是否滿足了客戶業務要求；
可用性，即衡量用戶使用軟件需要付出多大的努力；
可靠性，即軟件是否能夠一直處在一個穩定的狀態上滿足可用性；
高效性，即衡量軟件正常運行需要耗費多少物理資源；
可維護性，即衡量對已經完成的軟件進行調整需要多大的努力；
可移植性，即衡量軟件是否能夠方便地部署到不同的運行環境中；
三、提高代碼質量的具體經驗
1. 永遠不要復制代碼
不惜任何代價避免重復的代碼。如果一個常用的代碼片段出現在了程序中的幾個不同地方，重構它，把它放到一個自己的函數里。重復的代碼會導致你的同事 在讀你的代碼時產生困惑。而重復的代碼如果在一個地方修改，在另外一個地方忘記修改，就會產生到處是bug，它還會使你的代碼體積變得臃腫。
2. 測試你完成的代碼
你知道你的代碼能做什么，而且試了一下，它確實好用，但你實際上需要充分的驗證它。分析所有可能的邊界情況，測試在所有可能的條件下它都能如期的工作。如果有參數，傳遞一些預期范圍外的值。傳遞一個null值。如果可能，讓同事看看你的代碼，問他們能否弄壞它。單元測試是到達這種目的的常規方法。
3. 代碼審查
提交你的代碼之前，找個同事一起坐下來，向他解釋你做了哪些修改。通常，這樣做的過程中你就能發現代碼中的錯誤，而不需要同事說一句話。這比自己審查自己的代碼要有效的多得多。
4. 編寫不言自明的代碼
勿庸置疑，注釋是編程中很重要的一部分，但能夠不言自明的代碼跟勝一籌，因為它能讓你在看代碼時就能理解它。函數名變量名要慎重選擇，好的變量/方法名字放到語言語義環境中時，不懂編程的人都能看懂。
5. 不要使用純數字
直接把數字嵌入代碼中是一種惡習，因為無法說明它們是代表什么的。當有重復時更糟糕——相同的數字在代碼的多個地方出現。如果只修改了一個，而忘記了其它的。這就導致bug。一定要用一個命名常量來代表你要表達的數字，即使它在代碼里只出現一次。
6. 不要做手工勞動
當做一系列動作時，人類總是喜歡犯錯誤。如果你在做部署工作，並且不是一步能完成的，那你就是在做錯事。盡量的讓工作能自動化的完成，減少人為錯誤。當做工作量很大的任務時，這尤其重要。
7、不要試圖死磕代碼加快速度，找個更加有效的算法可能更加有效。
8、代碼要先做對，在弄快。先使其可靠，再讓其更快。先把代碼弄干凈，再讓它變快
9、當發現一個函數具有以下特征時，需要考慮抽取函數
(1)、過長
(2)、嵌套層數過深。
(3)、自然分塊，需要使用注釋描述該程序塊
(4)、判斷條件過於復雜
(5)、函數的某些判斷分支不斷變化
(6)、參數過於復雜
(7)、邏輯重復
10、局部變量應當用途單一
11、程序員應當將整潔的代碼風格作為一種習慣，時刻意識到整潔代碼的重要性並不斷地提高重構技巧
12、關於注釋
(1)、如果能用短小函數描述，則使用子函數替代注釋本身。
(2)、確保注釋和代碼表達的意圖一致，否則就失去了注釋的意義。
(3)、在重要的地方寫注釋，不要注釋滿天飛，簡單的重復代碼的功能是毫無意義的。要讓每一處注釋都有價值。不要過分注釋。
13、關於何時重寫代碼
開發團隊要預留20% 的時間用作保持對原有系統的重構。剩余的時間用作開發新功能。
只要有可能，所要重構的部分進行遞增修改，讓用戶切身感受到產品的改進，哪怕將工作時間延長。