劉宏韜 劉 偉,2 胡志剛

1(中南大學(xué)軟件學(xué)院 湖南 長沙 410075)2(湖南中醫(yī)藥大學(xué)管理與信息工程學(xué)院 湖南 長沙 410208)

基于抽象語法樹的數(shù)據(jù)泥團自動檢測研究

劉宏韜1劉 偉1,2胡志剛1

1(中南大學(xué)軟件學(xué)院 湖南 長沙 410075)2(湖南中醫(yī)藥大學(xué)管理與信息工程學(xué)院 湖南 長沙 410208)

數(shù)據(jù)泥團是一種常見的代碼味道，它將帶來重復(fù)代碼和維護難度增加等問題。針對大部分已有的代碼味道自動檢測工具無法檢測數(shù)據(jù)泥團，且檢測類型不全面等問題，提出一種基于抽象語法樹的數(shù)據(jù)泥團自動檢測方法。該方法在已有檢測工具的基礎(chǔ)上，增加了新的數(shù)據(jù)泥團類型，并加入了剔除冗余數(shù)據(jù)泥團和提取子數(shù)據(jù)泥團等步驟。通過對4個開源項目進行數(shù)據(jù)泥團實驗，結(jié)果表明方法具有較高的精確率，與Stench Blossom、inFusion等工具的數(shù)據(jù)泥團自動檢測功能相比，能夠檢測出一些其他工具無法檢測的數(shù)據(jù)泥團。同時，該方法具有較好的性能，執(zhí)行時間與系統(tǒng)規(guī)模成正比。

代碼味道 數(shù)據(jù)泥團 抽象語法樹 源代碼解析 重構(gòu)

0 引 言

代碼味道是指源代碼中存在的一些不良實現(xiàn)方案。軟件工程大師Martin Fowler和Kent Beck在文獻(xiàn)[1]中初次使用“代碼味道”一詞來描述這些不良實現(xiàn)方案，文獻(xiàn)中定義了22種常見的代碼味道，包括數(shù)據(jù)泥團、重復(fù)代碼、霰彈式修改等。此后，一些新的代碼味道[2]被學(xué)者和研究人員陸續(xù)提出。檢測、去除代碼味道對于提高代碼質(zhì)量具有非常重要的意義[3]，去除代碼味道能夠改善代碼的可維護性，因此應(yīng)當(dāng)對程序代碼中的代碼味道進行檢測和合理重構(gòu)，在不改變程序外部行為的前提下改善代碼的質(zhì)量。

開發(fā)人員往往在對代碼味道進行重構(gòu)之前，人工審查代碼、檢測代碼味道，這樣的方式效率低下，且正確率不高。近年來，自動檢測代碼味道已成為軟件工程領(lǐng)域的一個研究熱點。Liu等人[4-5]對泛化重構(gòu)機會檢測進行了研究，并基于概念關(guān)系、實現(xiàn)相似性等開發(fā)了一款重構(gòu)時機檢測工具。Maneerat等人[6]提出了從軟件設(shè)計模型的角度檢測代碼味道，將7種機器學(xué)習(xí)的算法運用于數(shù)項代碼味道數(shù)據(jù)集，并根據(jù)27個度量指標(biāo)檢測7種代碼味道，并對各種機器學(xué)習(xí)算法在代碼優(yōu)化方面的性能進行了評估。此外，針對檢測代碼味道這一問題也誕生了一些自動化工具。PMD[7]可以檢查源代碼中存在的過大類、重復(fù)代碼等代碼味道，它允許用戶自定義檢測這些代碼味道的閾值；CheckStyle[8]能夠探測代碼大小是否違規(guī)、類的設(shè)計是否良好，也能找出過長函數(shù)、過長參數(shù)列等代碼味道。

本文將以源代碼中數(shù)據(jù)泥團代碼味道為研究對象，提出了一種精確率及性能俱佳的數(shù)據(jù)泥團自動檢測算法，有助于軟件開發(fā)人員快速精準(zhǔn)地發(fā)現(xiàn)項目中存在的數(shù)據(jù)泥團代碼味道，為進一步的數(shù)據(jù)泥團重構(gòu)提供有力支持。

1 數(shù)據(jù)泥團和抽象語法樹

1.1 數(shù)據(jù)泥團

數(shù)據(jù)泥團[1]是22種常見代碼味道之一，它指代那些經(jīng)常捆綁出現(xiàn)的數(shù)據(jù)，如多個類中出現(xiàn)了相同的數(shù)個屬性，或多個方法中出現(xiàn)了相同的數(shù)個參數(shù)。對于類屬性數(shù)據(jù)泥團，應(yīng)當(dāng)使用提煉類,將數(shù)據(jù)提煉到一個獨立對象；對于方法參數(shù)數(shù)據(jù)泥團，應(yīng)當(dāng)使用引入?yún)?shù)對象。數(shù)據(jù)泥團的存在將增加系統(tǒng)的耦合度，自動檢測并重構(gòu)數(shù)據(jù)泥團，對數(shù)據(jù)實施集中式管理，可以提高代碼的可維護性和可復(fù)用性，進而增強系統(tǒng)內(nèi)聚性，降低耦合度，并提高代碼的可讀性、可擴展性等。Fontana等人[9]對現(xiàn)有的代碼味道自動檢測工作進行研究，發(fā)現(xiàn)對于數(shù)據(jù)泥團這一代碼味道，目前僅有inFusion[10]和Stench Blossom[11]兩款工具能作出自動檢測。

1.2 抽象語法樹

數(shù)據(jù)泥團的檢測工作基于對抽象語法樹AST(Abstract Syntax Tree)的分析，將指定項目源代碼轉(zhuǎn)換成抽象語法樹之后，再收集數(shù)據(jù)泥團檢測的相關(guān)信息。抽象語法樹是一種常用的程序代碼的中間表示形式。

本文使用Java語言為例，Eclipse JDT提供了Eclipse AST[12]用于將Java源代碼解析為抽象語法樹，并能對其進行節(jié)點的創(chuàng)建、修改。Eclipse AST中ASTNode類作為所有Java語法結(jié)構(gòu)節(jié)點的父類，它的子類如TypeDeclaration(類聲明)、MethodDeclaration(方法聲明)等都對相應(yīng)的語法結(jié)構(gòu)進行了明確地描述，并提供了大量的方法用于訪問該節(jié)點的屬性，如類名、方法參數(shù)列表等。此外，還提供了一個ASTVisitor類用于定義AST的抽象訪問者，在該類中聲明了一組訪問各類AST節(jié)點的方法，用于對各種類型的節(jié)點實施相應(yīng)的操作。

2 數(shù)據(jù)泥團自動檢測算法

考慮到檢測數(shù)據(jù)泥團后的重構(gòu)流程，本文所檢測的單個數(shù)據(jù)泥團將包含兩部分：

(1) 數(shù)據(jù)集 (Datum) 單個數(shù)據(jù)泥團所包含的數(shù)據(jù)。

(2) 位置集 (Location) 該數(shù)據(jù)泥團出現(xiàn)的位置。

本文主要針對數(shù)據(jù)類型、名稱(部分包括初始值)完全相同的情況，數(shù)據(jù)泥團中的數(shù)據(jù)將以如表1格式的字符串進行存儲。

表1 數(shù)據(jù)字符串格式

數(shù)據(jù)集來自對類屬性和方法參數(shù)的收集、計算和篩選，其中篩選主要依據(jù)以下兩項度量指標(biāo)：

(1) 重復(fù)度 (Repeat) 數(shù)據(jù)泥團出現(xiàn)的次數(shù)。

(2) 規(guī)模 (Size) 數(shù)據(jù)泥團的大小。

考慮到使用者檢測數(shù)據(jù)泥團需求的不同，數(shù)據(jù)泥團的重復(fù)度下限(minRepeat)和規(guī)模下限(minSize)兩項閾值將作為參數(shù)傳入，若一候選數(shù)據(jù)泥團重復(fù)度和規(guī)模均不小于重復(fù)度下限和規(guī)模下限(即Repeat≥minRepeat & Size≥minSize)，則將其判定為一個數(shù)據(jù)泥團，使用者可以根據(jù)需求自定義重復(fù)度和規(guī)模閾值以查找所需的數(shù)據(jù)泥團。

圖1 數(shù)據(jù)泥團自動檢測流程圖

數(shù)據(jù)泥團自動檢測流程如圖1所示，其中步驟解釋如下：

(1) 將源代碼解析為AST。

(2) 收集數(shù)據(jù)信息 遍歷AST中每一個類節(jié)點(TypeDeclaration)、匿名類節(jié)點(AnonymousClassDeclaration)和方法節(jié)點(MethodDeclaration)，對符合規(guī)模下限的類屬性和方法參數(shù)進行整理，得到數(shù)據(jù)信息列表。數(shù)據(jù)信息包含數(shù)據(jù)集和位置兩部分，數(shù)據(jù)集即所對應(yīng)的類屬性或方法參數(shù)以表1中的字符串格式存儲的字符串集合，位置即所對應(yīng)的類或方法所在的位置。

(3) 構(gòu)建候選數(shù)據(jù)泥團集 對數(shù)據(jù)信息列表中的每兩個數(shù)據(jù)信息p和q進行集合運算，將符合規(guī)模下限的結(jié)果存儲為數(shù)據(jù)泥團A，得到候選數(shù)據(jù)泥團集。其中A.datum = p.datum ∩ q.datum。之后需對候選數(shù)據(jù)泥團集按照數(shù)據(jù)集的規(guī)模，從大到小排序，以確保規(guī)模較大的數(shù)據(jù)泥團優(yōu)先被檢測。

(4) 合并重復(fù)數(shù)據(jù)泥團 對于候選數(shù)據(jù)泥團集中的每兩個候選數(shù)據(jù)泥團A和B，如果A和B兩者數(shù)據(jù)集相同，則將B的位置集合并到A的位置集中，并從候選數(shù)據(jù)泥團集中刪除B。

(5) 剔除冗余數(shù)據(jù)泥團 假設(shè)候選數(shù)據(jù)泥團集中存在{a, b}和{b, c}，它們都存在于方法func(a, b, c)，若將{a, b}確定為數(shù)據(jù)泥團并封裝為數(shù)據(jù)類A，則原參數(shù)列表將被修改為func(A, c)，參數(shù)列表中將不再存在數(shù)據(jù)泥團{b, c}，因此需要從候選數(shù)據(jù)泥團中刪除{b, c}。

(6) 提取子數(shù)據(jù)泥團 假設(shè)重復(fù)度閾值為2，func(a, b, c)中存在的數(shù)據(jù)泥團{a, b}被封裝成數(shù)據(jù)類A，原參數(shù)列表將被修改為func(A, c)，若{A, c}仍為滿足閾值要求的數(shù)據(jù)泥團并被封裝為類B，則需將{a, b}作為{A, c}的子數(shù)據(jù)泥團，即在重構(gòu)時B繼承A，且原參數(shù)列表修改為func(B)。

(7) 篩選數(shù)據(jù)泥團 根據(jù)輸入的規(guī)模下限和重復(fù)度下限對候選數(shù)據(jù)泥團集進行篩選，以得到最終數(shù)據(jù)泥團檢測結(jié)果。

數(shù)據(jù)泥團自動檢測算法偽代碼如表2所示。

表2 自動檢測算法偽代碼

該算法根據(jù)所處理內(nèi)容的不同，可劃分為兩個部分進行時間復(fù)雜度的分析。第一部分為數(shù)據(jù)信息的收集，該部分主要將代碼源文件轉(zhuǎn)換到抽象語法樹并進行遍歷進而收集數(shù)據(jù)信息，因此不難得知數(shù)據(jù)信息收集過程的時間復(fù)雜度為O(n)，n為源代碼文件的數(shù)量，即理論上運行時間隨著源代碼文件數(shù)量的增加而線性增加。第二部分為數(shù)據(jù)泥團的檢測，該部分主要針對第一部分中所收集的數(shù)據(jù)信息進行集合運算等一系列的處理，根據(jù)算法分析可知時間復(fù)雜度基本為O(n2)，n為第一部分中所收集的數(shù)據(jù)信息的數(shù)量，即理論上運行時間與數(shù)據(jù)信息數(shù)的平方成正比。

3 實驗結(jié)果分析

本文算法已嵌入到前期研究工作所開發(fā)的一款Eclipse插件SCORT[13]中。為了測試數(shù)據(jù)泥團的自動檢測效果，本文選取了同樣具有數(shù)據(jù)泥團自動檢測功能的工具inFusion和Stench Blossom與SCORT進行比較，三款工具檢測效果如表3所示。

表3 數(shù)據(jù)泥團自動檢測工具對比

由檢測效果可知：Stench Blossom[14]作為Eclipse插件，其檢測結(jié)果實時呈現(xiàn)在編輯器中，效率較慢，且只能針對當(dāng)前編譯單元(即當(dāng)前打開的文件)進行檢測，檢測效果一般；inFusion作為一款定期升級的商業(yè)軟件，檢測效果較好，且能針對整個工程進行檢測，與SCORT檢測效果相近，SCORT所檢測的數(shù)據(jù)泥團類型更為全面。為了驗證本文所述數(shù)據(jù)泥團的自動檢測算法的執(zhí)行效率和正確性，本文選取四個開源項目進行實驗，并為了與檢測效果相近的inFusion工具對比，因此使用與inFusion相同的閾值(即minRepeat=3、minSize=5)。本文選取了四個開源Java 項目，這四個項目規(guī)模和類型不一，基本信息如表4所示。

表4 待測項目基本信息

3.1 數(shù)據(jù)泥團檢測算法執(zhí)行效率實驗

實驗首先使用SCORT工具對四個項目進行數(shù)據(jù)泥團的檢測，并對算法執(zhí)行時間進行分析。對于每一個項目，數(shù)據(jù)泥團自動檢測算法均執(zhí)行5次，然后分別計算算法兩個部分的平均時間。數(shù)據(jù)泥團檢測實驗在一臺安裝Windows 7操作系統(tǒng)的PC機上進行，其配置為：雙核2.00 GHz，2 GB DDR2 RAM。數(shù)據(jù)泥團自動檢測算法包括數(shù)據(jù)信息的收集和數(shù)據(jù)泥團的檢測兩個部分，表4中四個待測項目的數(shù)據(jù)信息收集平均時間如表5所示。

表5 數(shù)據(jù)信息收集平均時間

由表5可知，隨著系統(tǒng)規(guī)模的增大(源文件數(shù)量的增加)，數(shù)據(jù)信息收集的平均執(zhí)行時間也逐步增加，以源代碼文件數(shù)為X軸，數(shù)據(jù)信息收集程序的執(zhí)行時間為Y軸，可得圖2所示源文件數(shù)-數(shù)據(jù)信息收集執(zhí)行時間圖。

圖2 源文件數(shù)-數(shù)據(jù)信息收集執(zhí)行時間圖

圖2中虛線為對實驗結(jié)果進行擬合的線性趨勢線，擬合方程為y=6.3957x+574.97，R2=0.9996。在數(shù)據(jù)信息收集部分，主要是將項目中的所有源文件轉(zhuǎn)換為抽象語法樹，并在抽象語法樹中根據(jù)條件收集數(shù)據(jù)信息，因此該部分執(zhí)行時間與源文件數(shù)量關(guān)系密切。因此從圖2中可以看到，執(zhí)行時間與系統(tǒng)規(guī)模(源文件數(shù)量)成正比，隨系統(tǒng)規(guī)模的增大執(zhí)行時間增加，整體呈現(xiàn)線性關(guān)系，算法具有良好的性能。

考慮到數(shù)據(jù)泥團的檢測部分算法執(zhí)行速度較快，因此該部分實驗將時間精確到納秒進行統(tǒng)計，并在表4中四個項目的基礎(chǔ)上追加六個開源項目，總共十個開源項目的數(shù)據(jù)泥團檢測部分執(zhí)行時間如表6所示。

表6 數(shù)據(jù)泥團檢測平均時間

由表6可知，隨著算法第一部分所收集的數(shù)據(jù)信息的數(shù)量增加，數(shù)據(jù)泥團檢測的平均執(zhí)行時間也逐步增加，以數(shù)據(jù)信息數(shù)為X軸，數(shù)據(jù)泥團檢測程序的執(zhí)行時間為Y軸，可得圖3所示數(shù)據(jù)信息數(shù)-數(shù)據(jù)泥團檢測執(zhí)行時間圖。

圖3 數(shù)據(jù)信息數(shù)-數(shù)據(jù)泥團檢測執(zhí)行時間圖

圖3中虛線為對實驗結(jié)果進行擬合的線性趨勢線，擬合方程為y=263.87x2+218990x+6E+06，R2=0.9719。在數(shù)據(jù)泥團檢測部分，主要是對前段算法所收集的數(shù)據(jù)信息進行集合運算，因此執(zhí)行時間與該項目所收集的數(shù)據(jù)信息關(guān)系密切。從圖3中的趨勢線可以看到，執(zhí)行時間與數(shù)據(jù)信息數(shù)的平方成正比。總體看來，本文中的數(shù)據(jù)泥團自動檢測算法執(zhí)行效率與系統(tǒng)規(guī)模成正比，執(zhí)行時間隨著系統(tǒng)規(guī)模的增加而增加，算法具有較好的執(zhí)行效率。

3.2 數(shù)據(jù)泥團檢測算法性能實驗

為了更好地評價數(shù)據(jù)泥團檢測結(jié)果，本文使用精確率(Precision)和召回率(Recall)來分析算法的性能，并結(jié)合人工審查判斷檢測結(jié)果是否正確，精確率和召回率分別表示為：

Precision=TP/(TP+FP)

(1)

Recall=TP/(TP+FN)

(2)

其中，真陽性TP(True Positive)表示工具檢測到的正確數(shù)據(jù)泥團數(shù)量；假陽性FP(False Positive)表示工具檢測到的錯誤數(shù)據(jù)泥團數(shù)量，即人工審查后發(fā)現(xiàn)檢測出的數(shù)據(jù)泥團是錯誤的；假陰性FN(False Negative)表示工具沒有檢測到，但人工審查后發(fā)現(xiàn)應(yīng)當(dāng)作為數(shù)據(jù)泥團檢測的數(shù)量。通過對檢測出的數(shù)據(jù)泥團進行逐個審查可以得到TP和FP值。

而對于FN值，由于人工查找正確的數(shù)據(jù)泥團難度較大，因此，實驗將既有成熟的代碼檢測工具inFusion檢測結(jié)果視為人工查找到的正確的數(shù)據(jù)泥團。SCORT和inFusion對表4中四個項目的數(shù)據(jù)泥團檢測結(jié)果如表7所示。

表7 SCORT與inFusion的數(shù)據(jù)泥團檢測結(jié)果

根據(jù)表7得到TP、FP和FN值，并計算出相應(yīng)的精確率和召回率，結(jié)果如表8所示。

表8 數(shù)據(jù)泥團自動檢測精確率與召回率

對于SCORT和inFusion兩款工具檢測結(jié)果的差異，以及召回率進行分析。表7中，兩款工具對于項目TinyUML的檢測結(jié)果相同；在項目Ice Hockey Manager的檢測結(jié)果中，SCORT檢測到了2個類屬性數(shù)據(jù)泥團，而inFusion由于沒有該項功能，因此沒有檢測結(jié)果；項目Abbot的檢測結(jié)果中，SCORT檢測到7個數(shù)據(jù)泥團，剔除了4個inFusion結(jié)果中存在的冗余數(shù)據(jù)泥團，另外檢測出3個來自于重寫方法的數(shù)據(jù)泥團，這些方法所在的類存在于同一繼承樹；項目Robocode的檢測結(jié)果中，SCORT檢測到13個數(shù)據(jù)泥團，剔除了3個inFusion結(jié)果中存在的冗余數(shù)據(jù)泥團，另外檢測出1個來自于重寫方法的數(shù)據(jù)泥團，以及1個類屬性數(shù)據(jù)泥團。

經(jīng)分析發(fā)現(xiàn)，檢測結(jié)果存在差異的主要原因為SCORT與inFusion工具所使用的算法的目的和對“數(shù)據(jù)泥團”概念的認(rèn)識不一。inFusion工具目的在于度量和評估軟件的質(zhì)量，且它所檢測的數(shù)據(jù)泥團僅為方法參數(shù)；SCORT目的在于檢測重構(gòu)時機，便于日后的重構(gòu)工作，因此將冗余數(shù)據(jù)泥團情況進行處理，并且SCORT所檢測的數(shù)據(jù)泥團包括了方法參數(shù)和類成員屬性。對于來自同一繼承樹的類成員屬性，以及來自重寫方法的參數(shù)，本文都認(rèn)為是需重構(gòu)的數(shù)據(jù)泥團。SCORT相較于inFusion所檢測的數(shù)據(jù)泥團類型更為全面，更符合數(shù)據(jù)泥團的定義。

4 結(jié) 語

代碼味道的自動探測與優(yōu)化對于提高軟件質(zhì)量具有重要意義，但針對“數(shù)據(jù)泥團”這一代碼味道的檢測算法和工具較少。本文研究了一套基于抽象語法樹的數(shù)據(jù)泥團自動檢測算法，該算法在以往研究成果的基礎(chǔ)上增加了檢測類成員屬性所組成的數(shù)據(jù)泥團，并提出剔除冗余數(shù)據(jù)泥團、提取子數(shù)據(jù)泥團，為日后的自動重構(gòu)工作做好鋪墊。

通過對4個開源項目進行數(shù)據(jù)泥團檢測實驗，結(jié)果表明，該方法精確率非常高，能夠正確檢測出源代碼中所有的數(shù)據(jù)泥團，實驗項目的數(shù)據(jù)泥團檢測精確率可達(dá)100%，并消除了所有的假陽性實例，與已有方法相比，其結(jié)果更全面；算法執(zhí)行效率較高，執(zhí)行時間與系統(tǒng)規(guī)模成正比，適用于各種規(guī)模的系統(tǒng)。

本文算法將類成員屬性與方法參數(shù)分開處理，且以字符串形式完全匹配而進行數(shù)據(jù)泥團的檢測，但在實際軟件開發(fā)過程中有著同時存在于屬性和參數(shù)的數(shù)據(jù)泥團，或變量名并不完全相同的數(shù)據(jù)泥團，在后續(xù)工作中，將逐步改進上述問題。此外，還將實現(xiàn)對數(shù)據(jù)泥團的自動重構(gòu)，例如將其自動封裝為數(shù)據(jù)類。

[1] Fowler M. Refactoring: improving the design of existing code[M]. Massachusetts: Addison-Wesley, 1999.

[2] Kerievsky J. Refactoring to patterns[M]. Massachusetts: Addison-Wesley, 2004.

[3] Emden E V, Moonen L. Java quality assurance by detecting code smells[C]//Proceedings of the Ninth Working Conference on Reverse Engineering (WCRE' 02), 2002: 97-106.

[4] Liu H, Ma Z, Shao W, et al. Schedule of bad smell detection and resolution: a new way to save effort[J]. IEEE Transactions on Software Engineering, 2012, 38(1): 220-235.

[5] Liu H, Niu Z, Ma Z, et al. Identification of generalization refactoring opportunities[J]. Automated Software Engineering, 2013, 20(1): 81-110.

[6] Maneerat N, Muenchaisri P. Bad-smell prediction from software design model using machine learning techniques[C]//Computer Science and Software Engineering (JCSSE), 2011 Eighth International Joint Conference on. IEEE, 2011: 331-336.

[7] Dangel A, Pelisse R. PMD[CP/OL]. (2013-05-01) [2013-05-04]. http://sourceforge.net/projects/pmd/.

[8] Burn O. CheckStyle[CP/OL]. (2012-10-12) [2013-05-04]. http://sourceforge.net/projects/checkstyle/.

[9] Fontana F A, Braione P, Zanoni M. Automatic detection of bad smells in code: An experimental assessment[J]. Journal of Object Technology, 2012, 11(2): 1-38.

[10] Intooitus SRL. inFusion[CP/OL]. (2012-10-31) [2013-05-04]. http://www.intooitus.com/products/infusion.

[11] Murphy-Hill E. Stench Blossom[CP/OL]. http://people.engr.ncsu.edu/ermurph3/tools.html.

[12] Thomas K, Eye M G, Olivier T. Eclipse corner article: abstract syntax tree[EB/OL]. (2006-11-20) [2013-05-04]. http:// www.eclipse.org/articles/article.php?file=Article-JavaCodeManipulation_AST/index.html.

[13] 劉偉, 劉宏韜, 胡志剛. 代碼缺陷與代碼味道的自動探測與優(yōu)化研究[J]. 計算機應(yīng)用研究, 2014, 31(1): 170-176.

[14] Murphy-Hill E, Black A P. An interactive ambient visualization for code smells[C]//Proceedings of the 5th International Symposium on Software Visualization. ACM, 2010: 5-14.

RESEARCH OF AUTOMATIC DETECTION FOR DATA CLUMPS BASED ON ABSTRACT SYNTAX TREE

Liu Hongtao1Liu Wei1,2Hu Zhigang11(SchoolofSoftware,CentralSouthUniversity,Changsha410075,Hunan,China)

2(SchoolofManagementandInformationEngineering,HunanUniversityofChineseMedicine,Changsha410208,Hunan,China)

Data Clumps is a common code smell, it will lead to issues such as duplicated code and increased difficulty in maintenance. As most existing code smell automatic detection tools fail to detect data clumps, and the detection type is not complete, a data clumps automatic detection based on abstract syntax tree is proposed. On the basis of existing detection tools, adding new types of data clumps to the algorithm, with some new steps as redundant data elimination and sub-data clumps extraction. Experiments are executed on 4 open source projects. Results show that the approach has high accuracy, and it is able to detect data clumps which other tools failed to detect, such as Stench Blossom, inFusion, etc. In addition, this approach has good efficiency and the execution time is directly proportionate to the size of system.

Code smell Data clumps Abstract syntax tree Source code parsing Refactoring

2015-12-03。國家自然科學(xué)基金項目(61272148)。劉宏韜，碩士生，主研領(lǐng)域：軟件工程。劉偉，高工。胡志剛，教授。

TP311.5

A

10.3969/j.issn.1000-386x.2017.01.003