２００１年在delphibbs做“首屆Delphi編程競賽”活動(http://www.delphibbs.com/delphibbs/dispq.asp?lid=650664)的時候，曾就代碼的規范性與品質問題與大家進行過討論，摘錄一些言論如下：

=========================

3. 我們公司有個程序員，現在是項目經理。他原本是做圖形程序開發的，我看過它的一個工具的代碼，OHHHH，我當時差點沒有昏倒。——它的代碼做得就象方塊，每一行幾乎都一個樣子，似乎都在不斷重復。但是，這些代碼的運行效率居然比我見到的所有圖形開發包都快！

所以，我絕對同意“一個真正優秀的方案可能代碼很多，很精巧，也很復雜，但絕對在效率、速度上非普通方案可比”、“大道深處又至簡，一個非常出色的方案往往可以化復雜為簡單，化腐朽為神奇，達到代碼即方案，代碼即解釋，恍恍乎游刃有余”和“最出色的代碼不是代碼本身，而是代碼體現出來的出神入化的思維和境界。到達這個境界，代碼多少已經不再重要了”這樣的觀點。

4. 代碼的規范性我深有體會。我們公司現在正在展開的也是一個叫“代碼格式化規范”的動作。

但我要說的是一個小故事，我的一個組員總是在說我的代碼他看不懂，這看不懂那也看不懂；而另一個組員呢，將我一個寫了兩年的項目那個去看了一個多月，說懂了。前一個組員總是說我的代碼不“規范”，不“格式化”，用了太多的技巧，不用標準的寫法；而后一個組員卻什么也不說。兩個組員最大的不同是：前一個組員只有兩年的編程經驗，而后一個，有十年的編程經驗。

如果，如果你用Delphi來寫一個“操作系統級程序”，那么，你能用到的“標準的寫法”可能沒幾個，你可能必須用各種各樣的技巧，各種各樣離奇的思想。這不是一般人能夠想到的做到的。有興趣的人可以去看看QString這個字符串處理單元，那絕對是不好讀的代碼，也絕對精煉，效率也絕對高。但可能絕對“不標準”、“不規范”。

我并不是反對“代碼格式化”，我只是說，我們在這里開展一個競賽，重點并不是要去格式化代碼，我們的主旨是“寫出好的思想”和“好的代碼”。那些格式化中存在的各種各樣的注釋和格式化用的空格，自然有工具去過濾掉它，你不必關心它們影響你的代碼字節數。

5. 這個競賽的確是在“鼓勵提高個人能力”，但絕對沒有“忽視團隊精神”的意思。哈哈。

我們一直忽略了這點，沒有提出來說，算是我的工作失誤。其實中國現在的“程序高手”很多，但真正懂得“軟件工作”和組織“團隊開發”的人才之又少。事實上我現在也正在學這個，正在帶開發組，正在從最小的“團隊”做起。——我自認還做得非常非常差。印度培養出來的程序員象一個個標準大小的方塊，任意多塊放在任意位置都是有用的，但缺乏靈魂；中國培養出來的程序員象一個個釘子，放哪里打都好用，靈氣十足，能力十足，但一大堆釘子放在一起，你的手碰都不敢碰一下。

但中國的程序員在國外卻是極好的。因為人家懂得如何組織釘子開發，而不是只懂得如何將方塊“積木”在一起。

不要因為中國沒有好的項目管理人員，就要求所有的程序員全變成方塊，這是舍本而逐末的事。

6. 好的雕刻師必須先是好的木匠，藝人必須先是匠人。

=========================

最后這句“藝人必須先是匠人”，我后來還在《Delphi實現可執行文件之源碼詳解》中引用過：

=========================

必先是匠人，之后才會是藝人，再之后才會是藝術家。程序員就是程序員，如果不靜下心來做代碼，好高騖遠則終將一無所成。

志存高遠而腳踏實地，此實地者，源碼也。

轉載于:https://www.cnblogs.com/java0818/archive/2005/12/04/2144594.html

總結

以上是生活随笔為你收集整理的代码规范性与品质问题～的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。