2010-11-18 56 views
5

我必須對代碼庫執行大的更改,該代碼庫由幾個不同類型的更改組成,這些更改需要在數百個不同位置應用,分佈在數十萬個線。代碼審查工具,用於準備大量更改爲代碼庫

我有一個工具的想法,可以幫助我,但我確信我不是唯一一個這個想法,我不知道它是否已經寫好。

讓我勾勒出它是如何工作的:

  • 首先,有點像用grep的背景下,它會收集一套基於正則表達式的代碼「有趣」的塊;可能有成千上萬的這些地點。
  • 然後,讓我遍歷塊,依次標記爲有趣或無趣。這基本上是儘可能地自動化將潛在變更地點削減到實際變更地點的人工工作。
  • 最後,讓我對所有選定的感興趣的位置應用一個轉換(例如sed樣式替換)。

此工具已存在?

我正在考慮自己寫這個工具,如果我找不到預先存在的工具。

+2

如果您找不到合適的工具,並且必須自己創建一個。如果你開源,它會很棒。有很多地方我會喜歡有一個類似的工具,你的建議。 – sdolan 2010-11-18 17:56:44

回答

1

這聽起來類似於Coccinelle寫做,雖然它只有C.

+0

這很有趣,但我認爲Coccinelle的方法可能過於結構化而不切實際;換句話說,它試圖自動化太多,但是在編寫語義補丁時卻出現了另一方面的複雜性。因爲變更集不需要重複使用,所以我認爲最好在務實的情況下進行實用的一次性手動選擇。 – 2010-11-18 18:53:51

1

我不知道的一樣,任何工具的工作原理。這似乎是一項相當專業化的任務,只能在一段時間內完成,所以通過開發和分發這樣的工具很難賺錢。

過去,如果我有這樣的任務,我會在Emacs的Lisp版本中編寫腳本。 Lisp是一個強大的語言,Emacs編輯器有許多方便的內置函數(例如query-replace-regular-expression)和概念。但是,除非您已經熟悉Emacs和Lisp,否則我不會推薦它。學習曲線太陡。

+0

我想到的工具將是一個200行的黑客工作,以最大限度地減少(工具創建+重構)的總工作時間,而不是某些拋光產品。 query-replace-regular-expression並不比sed的命令多很多;作爲第一遍,我的工具可能會提取要修改成大文本文件的塊,手工削減,然後用sed,awk等進行修改,然後重新與原始集成。 – 2010-11-19 01:37:27

1

聽起來很有趣。我也玩過這樣的想法,但沒有遠離命令行腳本。我對重構準備的做法是:

  1. 查找代碼chunc是 重構
  2. 生成REG-EXP /腳本 尋找類似碼/圖案和 創建位置的列表這個 類型圖案

輸出文件包含在GNU或MS輸出格式線(例如:文件:LINE MESSAGE) 因此,它可以在任何IDE被加載(VIM的-q)和碼塊可以發現輕鬆地通過雙擊「錯誤消息的」。

順便說一下,如果以前通過縮進統一了代碼,則grep更容易。

1

這聽起來像你打算通過使用hueristics(「grep」)來找到你的代碼和啓發式(「sed」)來修改你的代碼。如果這些技巧能夠訣竅,並且你可以像你說的那樣真正做到200行,那麼你甚至會在這裏問到我感到很驚訝。

作爲一般規則,使用啓發式方法進行數百次更改是相當危險的。如果一個人參與其中每一個人,他可以在他注意到他們的程度上修正錯誤,並且這可能足夠好;在這種情況下,你正在構建一個有趣的文本編輯器。如果你走這條路,EMACS可能是一個非常好的選擇,因爲你想要的所有動作(字符串搜索,提取到緩衝區的顯示,字符串替換,側面的構建標記數據結構)在Elisp中完全可編寫腳本它已經有了一個不錯的用戶界面。

如果您想在更可靠的基礎上實現自動化,您需要準確的搜索和替換。我們的DMS Software Reengineering Toolkit是一個 程序轉換工具,可以爲許多廣泛使用的語言(您沒有說你正在做哪一個)做到這一點,包括Java,C++,C,C#,COBOL,... DMS可以完全腳本化自定義操作集。

+0

嗯,我可以在200行以內完成,但是它會逐漸難以簡潔地撰寫,並涉及更多手動步驟:) - 查看grep -n -C 10的輸出重定向到文本文件,然後進行後處理放入差異中,最後貼上補丁。但是圍繞這種工作流程設計的可視化界面 - 它本質上是一個工作流程問題 - 會讓生活變得更加輕鬆。自動化不是重點;與此相關的整個問題就是對每個案件的重複審查。 – 2010-11-25 04:13:20