Studying the Effect of Refactorings: a Complexity Metrics Perspective

Refactoring is widely recognized as a way to improve the internal structure of a software system in order to ensure its long-term maintainability. Consequently, software projects which adopt refactoring practices should see reductions in the complexity of their code base. We evaluated this assumption on an open source system ---namely PMD, a Java source code analyzer--- and discovered that periods of refactorings did not affect the cyclomatic complexity. This paper investigates this counterintuitive phenomenon through a detailed analysis of the actual source code manipulations applied on the system under study.

Transcript

1. Ansymo Antwerp Systems and Software Modelling Quinten David Soetens Serge Demeyer Studying the Effect of Refactorings: a Complexity Metrics Perspective
2. [Lehman & Belady: Program Evolution: processes of software change (1985)] Lehman’s Laws 2
3. [Lehman & Belady: Program Evolution: processes of software change (1985)] Lehman’s Laws I. Continuing Change: “A system must be continually adapted or it becomes progressively less satisfactory.” 2
4. [Lehman & Belady: Program Evolution: processes of software change (1985)] Lehman’s Laws I. Continuing Change: “A system must be continually adapted or it becomes progressively less satisfactory.” II. Increasing Complexity: “As a system evolves its complexity increases unless work is done to maintain or reduce it.” 2
5. [Lehman & Belady: Program Evolution: processes of software change (1985)] Lehman’s Laws I. Continuing Change: “A system must be continually adapted or it becomes progressively less satisfactory.” II. Increasing Complexity: “As a system evolves its complexity increases unless work is done to maintain or reduce it.” Solution = REFACTORING 2
6. BUT! Does refactoring really decrease complexity? 3
7. BUT! Does refactoring really decrease complexity? 3
8. Related work Studies on the effect refactoring has on: •Quality •Understandability •Changeability •Reusability •Maintainability •Coupling & Cohesion Mixed conclusions!! 4
9. Related work Studies on the effect refactoring has on: •Quality •Understandability •Changeability •Reusability •Maintainability •Coupling & Cohesion Mixed conclusions!! 4 What about Complexity??
10. McCabe Cyclomatic Complexity • Measure for amount of decision logic (control flow complexity) per method. • Count nr of branches (for, while, if, do, case, catch.... ) • Count nr of boolean operators ( && , || ) • Nr of independent paths through control flow graph 5
11. McCabe Cyclomatic Complexity • Measure for amount of decision logic (control flow complexity) per method. • Count nr of branches (for, while, if, do, case, catch.... ) • Count nr of boolean operators ( && , || ) • Nr of independent paths through control flow graph 5 public Rule getRuleByName(String ruleName) { for (Iterator i = rules.iterator(); i.hasNext();) { Rule r = (Rule)i.next(); if (r.getName().equals(ruleName)) { return r; } } throw new RuntimeException(.....); }
12. McCabe Cyclomatic Complexity • Measure for amount of decision logic (control flow complexity) per method. • Count nr of branches (for, while, if, do, case, catch.... ) • Count nr of boolean operators ( && , || ) • Nr of independent paths through control flow graph 5 public Rule getRuleByName(String ruleName) { for (Iterator i = rules.iterator(); i.hasNext();) { Rule r = (Rule)i.next(); if (r.getName().equals(ruleName)) { return r; } } throw new RuntimeException(.....); }
13. McCabe Cyclomatic Complexity • Measure for amount of decision logic (control flow complexity) per method. • Count nr of branches (for, while, if, do, case, catch.... ) • Count nr of boolean operators ( && , || ) • Nr of independent paths through control flow graph 5 public Rule getRuleByName(String ruleName) { for (Iterator i = rules.iterator(); i.hasNext();) { Rule r = (Rule)i.next(); if (r.getName().equals(ruleName)) { return r; } } throw new RuntimeException(.....); } CC = 3
14. 6 Theoretical Empirical Results Conclusion
15. 6 Theoretical
16. Theoretical Approach 7 Refactoring Complexity Change Pull Up Method Extract Method Inline Method C 1 = C 0 + CC Method − CC Method N C 1 = C 0 + CC Method − (CC Method −1)N C 1 = C 0 − CC Method + (CC Method −1)N Theoretical
17. Pull Up Method 8 0 1 2 3 4 5 0 1 2 3 4 5 N CC Decrease Equalize Increase Theoretical C 1 = C 0 + CC Method − CC Method N CC Method − CC Method N < 0 CC Method − CC Method N = 0 CC Method − CC Method N > 0
18. 9 0 1 2 3 4 5 0 1 2 3 4 5 N CC Theoretical Extract Method C 1 = C 0 + CC Method − (CC Method −1)N Decrease Equalize Increase CC Method − (CC Method −1)N < 0 CC Method − (CC Method −1)N = 0 CC Method − (CC Method −1)N > 0
19. Extract Method (Equalize) 10 the rest of this section. We take ystem before the refactoring, C1 em after the refactoring and x as d upon which the refactoring is ng ctoring we move a method from ubsequently remove the duplicate bling classes. Suppose c is the d occurred (i.e., the number of hen we can write the complexity 0 + x − cx ed by adding a method in the ently removing the method from nted it (−cx). We can now see he same when only one (c = 1) m the subclasses (which is ba- ation). When more occurrences complexity will be lower. The e if no occurrences are removed ), but then we would simply add ass and this would no longer be ng oring creates a new method from n, occurrences of this code are wly created method. If we take es of the extracted piece of code d call, we can write the changed the for loop to a new method bar, as is shown on the right then the complexity of the method foo is reduced to two and the complexity of the new method is also two. So the total complexity remains four. public void foo(){ if(condition){ for(iteration){ ... } } for(iteration){ ... } } Listing 1. Before an Extract Method refactoring. public void foo(){ if(condition){ bar(); } bar(); } public void bar(){ for(iteration){ ... } } Listing 2. After an Extract Method refactoring. C. Inline Method Refactoring The Inline Method refactoring is the inverse of the Extract Theoretical
20. Extract Method (Equalize) 10 the rest of this section. We take ystem before the refactoring, C1 em after the refactoring and x as d upon which the refactoring is ng ctoring we move a method from ubsequently remove the duplicate bling classes. Suppose c is the d occurred (i.e., the number of hen we can write the complexity 0 + x − cx ed by adding a method in the ently removing the method from nted it (−cx). We can now see he same when only one (c = 1) m the subclasses (which is ba- ation). When more occurrences complexity will be lower. The e if no occurrences are removed ), but then we would simply add ass and this would no longer be ng oring creates a new method from n, occurrences of this code are wly created method. If we take es of the extracted piece of code d call, we can write the changed the for loop to a new method bar, as is shown on the right then the complexity of the method foo is reduced to two and the complexity of the new method is also two. So the total complexity remains four. public void foo(){ if(condition){ for(iteration){ ... } } for(iteration){ ... } } Listing 1. Before an Extract Method refactoring. public void foo(){ if(condition){ bar(); } bar(); } public void bar(){ for(iteration){ ... } } Listing 2. After an Extract Method refactoring. C. Inline Method Refactoring The Inline Method refactoring is the inverse of the Extract Theoretical CC = 4
21. Extract Method (Equalize) 10 the rest of this section. We take ystem before the refactoring, C1 em after the refactoring and x as d upon which the refactoring is ng ctoring we move a method from ubsequently remove the duplicate bling classes. Suppose c is the d occurred (i.e., the number of hen we can write the complexity 0 + x − cx ed by adding a method in the ently removing the method from nted it (−cx). We can now see he same when only one (c = 1) m the subclasses (which is ba- ation). When more occurrences complexity will be lower. The e if no occurrences are removed ), but then we would simply add ass and this would no longer be ng oring creates a new method from n, occurrences of this code are wly created method. If we take es of the extracted piece of code d call, we can write the changed the for loop to a new method bar, as is shown on the right then the complexity of the method foo is reduced to two and the complexity of the new method is also two. So the total complexity remains four. public void foo(){ if(condition){ for(iteration){ ... } } for(iteration){ ... } } Listing 1. Before an Extract Method refactoring. public void foo(){ if(condition){ bar(); } bar(); } public void bar(){ for(iteration){ ... } } Listing 2. After an Extract Method refactoring. C. Inline Method Refactoring The Inline Method refactoring is the inverse of the Extract Theoretical CC = 4 CC = 2 CC = 2
22. Extract Method (Equalize) 10 the rest of this section. We take ystem before the refactoring, C1 em after the refactoring and x as d upon which the refactoring is ng ctoring we move a method from ubsequently remove the duplicate bling classes. Suppose c is the d occurred (i.e., the number of hen we can write the complexity 0 + x − cx ed by adding a method in the ently removing the method from nted it (−cx). We can now see he same when only one (c = 1) m the subclasses (which is ba- ation). When more occurrences complexity will be lower. The e if no occurrences are removed ), but then we would simply add ass and this would no longer be ng oring creates a new method from n, occurrences of this code are wly created method. If we take es of the extracted piece of code d call, we can write the changed the for loop to a new method bar, as is shown on the right then the complexity of the method foo is reduced to two and the complexity of the new method is also two. So the total complexity remains four. public void foo(){ if(condition){ for(iteration){ ... } } for(iteration){ ... } } Listing 1. Before an Extract Method refactoring. public void foo(){ if(condition){ bar(); } bar(); } public void bar(){ for(iteration){ ... } } Listing 2. After an Extract Method refactoring. C. Inline Method Refactoring The Inline Method refactoring is the inverse of the Extract Theoretical CC = 4 CC = 2 CC = 2 CC = 4
23. 11 0 1 2 3 4 5 0 1 2 3 4 5 N CC Theoretical Inline Method Decrease Equalize Increase CC Method − (CC Method −1)N < 0 CC Method − (CC Method −1)N = 0 CC Method − (CC Method −1)N > 0 C 1 = C 0 − CC Method + (CC Method −1)N
24. 12 Theoretical Empirical Results Conclusion
25. 12 Theoretical Empirical Results Conclusion
26. 12 Theoretical Empirical
27. Empirical Validation • • Analysis of revisions 17 to 810 ≈ 776 revisions • = 2 months of development • Metric for each revision extracted using “Metrics” Eclipse Plugin 13 http://pmd.sourceforge.net/ Empirical
28. Revisions with Refactorings 14 Empirical
29. Revisions with Refactorings 14 33 out of 776 (4.25%) of revisions mention “refactor” in comment Empirical
30. 15 Theoretical Empirical Results Conclusion
31. 15 Theoretical Empirical Results Conclusion
32. 15 Theoretical Empirical Results
33. Results 16 !""# $""# %""# &""# '""# (""# )""# *""# +"""# ++""# "# +""# !""# $""# %""# &""# '""# (""# )""# !"#$%&'()*+ ,&-(.("/+ !"#$%&'()*+0-"%12"/+ Results
34. Results 16 !""# $""# %""# &""# '""# (""# )""# *""# +"""# ++""# "# +""# !""# $""# %""# &""# '""# (""# )""# !"#$%&'()*+ ,&-(.("/+ !"#$%&'()*+0-"%12"/+ Results
35. Results 16 !""# $""# %""# &""# '""# (""# )""# *""# +"""# ++""# "# +""# !""# $""# %""# &""# '""# (""# )""# !"#$%&'()*+ ,&-(.("/+ !"#$%&'()*+0-"%12"/+ Results
36. Results 17 !" #!" $!" %!" &!" '!" (!" )!" *!" +!" ,-./0" 1/234-50/6" !"#$"%&'()*' +,-./"01&2'+34%5"6' 7893:;</6"==" >?40/3@/6"==" A/40/3@/6"==" Results
37. Results 17 Results !" #!!" $!!" %!!" &!!" '!!" (!!" )!!" *+,-." /-012+3.-4" 567189:-4";;" <=2.-1>-4";;" ?-2.-1>-4";;"
38. Observations • Refactorings that cause Decreased CC • Removal of duplicated code (Extract Method or Pull Up Method) (6 cases) • Inline a Method, that is only called once (4 cases) • Removal of dead code (4 cases) 18 Results
39. Observations • Refactorings that cause? Increased CC • Extract Method of single occurrence of a piece of code (1 case) • Addition of new functionality besides refactoring (“Floss Refactoring”) (7 cases) 19 Results
40. Observations • Refactorings that cause Equalized CC • Introduce Explaining Variable (2 cases) • Rename Method (1 case) • Special Case of Extract Method (1 case) 20 Results
41. Observations • Decreased CC not caused by Refactoring • Mostly due to removal of unnecessary methods / functionality. 21 Results
42. 22 Theoretical Empirical Results Conclusion
43. 22 Theoretical Empirical Results Conclusion
44. 22 Theoretical Empirical Results Conclusion
45. Conclusions • Refactoring doesn’t always affect (Cyclomatic) Complexity • “Floss Refactoring” often applied by developers • Threats: • Other complexity metrics? • Use of commit messages to identify refactorings? • Only looked at “initial development” phase 23 Conclusion