2010-09-02 29 views
3

我們使用代碼靜態分析工具(Sonar)來檢測我們項目中的重複代碼。看起來代碼中有很多重複實例,但其中大多數實例少於10行,只出現一次。在Stackoverflow社區的'意見'中,您應該如何在整合代碼重複時劃定界限?例如,對於單個重複項應該是> = 10行,還是應該考慮重複行的總數,例如。考慮>重複出現10次以上。 對於上下文,我正在看的編程語言是Java和ActionScript。 我意識到這個問題可能不會得出明確的答案,但在這個問題上的一些明確的指導可以爲我節省大量的時間重構代碼(或增加時間:)何時合併代碼重複

回答

2

合併代碼,如果它的目的相同,並且您希望將應用於一個副本的所有更改應用於其他副本。你可能並不總是希望這種事情發生。爲了滿足不同的需求,你可能有兩塊代碼,幾乎完成同一件事,但完全填充完全不同的目的。需求波動很快,你可能會發現,你統一的部分跟不上發生在不同方向的轉變(這是我經常碰到的情況,當這種情況過度時)。

所以規則很簡單:合併代碼,做同樣的事情。不管多久。你不想在1000個地方做出同樣的改變。不要試圖合併代碼段,除非您發現它們有足夠的共同點,可以將其重構爲有用的子程序,否則偶爾會出現相似的代碼段。請記住,性能關鍵代碼並不是最佳實踐的最佳選擇。

格爾茨
back2dos

+0

還要記住,性能關鍵代碼並不是最佳實踐的最佳場所。 小心這種推理。通常情況下,「過早優化是所有惡魔的根源」,而性能關鍵代碼只有經過驗證的好處纔會變得難看:) – 2010-09-03 09:29:47

5

如果他們是實際重複,儘快合併您可以。你離開的時間越長,副本越分散,越難。另外,當有人遇到一堆副本並需要做一個「快速修復」時,他們會製作更多副本,但一個乾淨的代碼庫鼓勵大家保持乾淨。

2

理想情況下:現在合併。

更實際:對於像你這樣的小細分市場來說,一個好的測試就是檢查你是否爲你找到的代碼定義了一個有意義的目的。如果代碼的目的可以用幾個字來概括,那麼您可能可以將其移到單獨的函數中。如果你不能總結它,但它仍然是重複的,我會說離開它。

理想情況下,您的代碼不應該允許這樣做,但在大多數代碼中,多個事物最終會進入一個子例程 - 例如打開套接字併發送數據包的代碼。理想情況下,這些是不同的東西,因此它們是不同的功能。如果你的產品代碼不是完美的,那麼最終可能會導致套接字代碼的結束和數據包代碼的開始(相當於約10行),然後再進行更改。如果這些匹配,但你不能用幾個字來描述它的功能,那麼留下它並在你有時間時重新分配其餘的代碼。

2

僅當它具有共同目的時才合併代碼(特別是像您提到的10行這樣的小塊)。如果代碼片段真的做了不同的任務(但實現恰好相同),那麼從合併它們的設計角度來看沒有任何好處,並且如果您確實需要將它們再次拆分出來。