我不這麼認為。大多數情況下,更少的程式碼往往語義更模糊,更難理解(因此更難維護)。
當我使用jBehave工作和測試元過濾時,我寫了類似於下面的程式碼:
public Embedder configuredEmbedder() { Embedder embedder = super.configuredEmbedder(); ignoreStoriesAndScenariosWithMetaInformationParameter(embedder, "ignore"); return embedder; } private void ignoreStoriesAndScenariosWithMetaInformationParameter(Embedder embedder, String ignoreParameter) { embedder.useMetaFilters(Arrays.asList("-" + ignoreParameter)); }
在之後對這些程式碼的討論中,我的一個同事表示,他剛剛刪除了一些“沒有必要”的私有方法,於是程式碼變成了這樣:
@Override public Embedder configuredEmbedder() { Embedder embedder = super.configuredEmbedder(); embedder.useMetaFilters(Arrays.asList("-ignore")); return embedder; }
顯然,方法更短,程式碼更少了。對我們來說,使用這樣的類,或許能讓我們在工作時對這個方法所發生的變化一目瞭然。但是如果有新加入專案的人呢,並且這傢伙之前從未使用過jBehave呢?對他而言,長一點的程式碼反而可以獲取更多的資訊,即使他不知道jBehave是如何工作的,不清楚“元過濾器”是什麼,不懂minus的意思——但是至少能理解我們想要實現的目標。
當我試圖解釋自己的看法時,其他開發人員雖然同意我的觀點,但卻認為通過新增註釋也可以達到相同的效果。是的,我完全同意,新增註釋肯定是有效的。這只是風格問題。我個人不喜歡註釋而已,不過,在上述這種情況下,或許註釋的確是更好的選擇,因為我們可以通過註釋解釋元過濾器程式碼和jBehave層檔案之間的聯絡。
所以最後,程式碼成了這樣的:
@Override public Embedder configuredEmbedder() { Embedder embedder = super.configuredEmbedder(); // ignore stories and scenarios with meta information parameter @ignore. embedder.useMetaFilters(Arrays.asList("-ignore")); return embedder; }
當然你可以說,這樣一個小小的事例不值一提。但是,一個專案的風格,我認為是非常重要的。你也可以通過討論具體的例子找到一種普遍的風格。也許其他開發人員會因此而考慮他的程式碼是否會給新加入的同事帶來困惑,從而去新增註釋,而不是將方法縮成減一行程式碼。
結論
乾淨的程式碼並不總意味著更少的程式碼。所以,你需要在編寫更多的小方法和縮減程式碼行數之間權衡得失。關於編碼風格,以後我會再發帖子予以討論。
評論(1)