FOR0383 Software Quality Assurance

Transcription

1 This method seems much, much bigger than all the other methods. FOR0383 Software Quality Assurance Lecture 15 Code metrics "You cannot control what you cannot measure." Tom DeMarco 2/11/2009 Dr Andy Brooks 1

2 Identifying poorly written code How good is the code under development? Fixing defects after a system has been released to a customer can be very expensive. A single bug report can easily require 20 hours of effort before the defect is identified and fix. How should a bug report be written? Code metrics can be used to identify poorly written methods, classes, and packages before release to the customer. Using code metrics involves specifying the method used to make the measurement and the nature of the underlying measurement scale. Does it really make sense to add together complexity measures in the same way we can add two real numbers together? 2 +2 is 4 but is a complexity of 2 + a complexity of 2 = a complexity of 4? 2/11/2009 Dr Andy Brooks 2

3 Warning: code metrics are still not standardized. Researchers are still standardizing code metrics (specifying the method used to make the measurement). Does this metric include or exclude constructor methods? Does this metric include or exclude get and set methods? Does this metric include or exclude // end-of-line comments? Does this metric include or exclude empty lines? Does this metric view the base class as depth 0 or 1? Does this metric include or exclude the API? Does this metric include or exclude default statements? Existing code metric tools can disagree on the method used to make what is supposed to be the same measurement. 2/11/2009 Dr Andy Brooks 3

4 Warning: code metrics are still not fully validated. Researchers are still validating code metrics. Does a high value for a code complexity metric always mean that the code is poorly written? If an application is complex, the code will be complex. Identically functional code rewritten with single identifiers and poor use of spacing and indentation might have the same value for the complexity metric yet be a lot more difficult to understand and maintain. Underlying measurement scales are often not interval: the operation of adding, subtracting, multiplying, and dividing do not have the same meaning as they do for real numbers. This is a controversial issue. The correlation of the values of an individual code metric with defects can often be less than 0.4. The best models to identify poorly written code combine several code metrics. 2/11/2009 Dr Andy Brooks 4

5 fylgnistuðull Some plots illustrating correlations of various sizes ideally, correlations should be > /02/2009 Dr Andy Brooks 5

6 outlier/enfari Identifying outliers can be useful In a box plot, the box contains 50% of the data set. the interquartile range (IQR) 1.5* IQR away from the box, a value is a suspected outlier 3.0*IQR away from the box, a value is deemed an outlier A method, class, or package with an outlier value for a metric is worth examining closely. Ask yourself: Is the code poorly written? Should the code be rewritten? 11/02/2009 Dr Andy Brooks 6

7 as documented for the RefactorIT plug-in for Eclipse LOC Total Lines of Code LOC/ Source Lines of Code SLOC / Effective Lines of Code ELOC The Total Lines of Code metric counts all lines regardless of whether they contain code, comments, or white space. If a class exceeds 1000 lines, it is advisable to split up the class and use delegation. RefactorIT calculates LOC as follows: Method body lines are only counted for a method; class and interface body lines are only counted for a class or interface; lines of all source files belonging to a package are counted for the package. The implications are: Method declarations and Javadoc comments are not counted on the method level. They are counted on the class / interface and package levels. Class or interface declarations and Javadoc comments are not counted on the class / interface level. They are counted on the package level. 2/11/2009 Dr Andy Brooks 7

8 LOC for the class containing the code below is incremented by 17 due to the code lines labelled c and m. LOC for the broadcast method itself is 9 (lines labelled m): c /** c * Sends broadcast message c * c <true> if message successfully sent; c * <false> otherwise. c */ c public boolean broadcast(message message) { m // Sends broadcast message m // to all registered clients m if (!istransportavailable()) { m return false; // Message not sent m } m m gettransport().broadcast(message); m m return true; // Message sent c } 2/11/2009 Dr Andy Brooks 8

9 as documented for the RefactorIT plug-in for Eclipse Comment Lines of Code (CLOC) CLOC counts all lines that contain regular comments and Javadoc comments where empty lines within both kinds of comments are also counted. Furthermore, RefactorIT consider the following factors in the CLOC calculation: Only comments inside a method body are counted for a method. Only regular comments and Javadoc comments inside a class or interface body are counted for classes and interfaces. Regular comments and Javadoc comments of all source files belonging to a package are counted for the package. The implications are: Javadoc comments for a method are not counted on the method level. They are counted on the class / interface and package levels. Javadoc comments for a class or interface are not counted on the class or interface level. They are counted on the package level. 2/11/2009 Dr Andy Brooks 9

10 RefactorIT recommends a commenting of at least 20% of the code and a maximum of 40%. In the following example we have a broadcast method where CLOC is 4 (lines labelled m) and totally for this class CLOC is incremented by 10 (lines labelled c and m): c /** c * Sends broadcast message c * c <true> if message successfully sent; c * <false> otherwise. c */ public boolean broadcast(message message) { m m // Sends broadcast message // to all registered clients if (!istransportavailable()) { m return false; // Message not sent } gettransport().broadcast(message); m return true; // Message sent } 2/11/2009 Dr Andy Brooks 10

11 as documented for the RefactorIT plug-in for Eclipse þétta athugasemda Density of Comments (DC) Density of Comments (DC) provides the ratio of comment lines (CLOC) to all lines (LOC). Hence, DC = CLOC / LOC. The density of comments value will be between 0.0 and 1.0 and it can be used as a quality indicator to see how much of the code is commented. RefactorIT recommends a commenting of at least 20% of the code and a maximum of 40%. Thus, the lower limit for density of comments is 0.2 and the upper recommended value is 0.4. Confer with CLOC and LOC to see how RefactorIT evaluates these values. 2/11/2009 Dr Andy Brooks 11

12 as documented for the RefactorIT plug-in for Eclipse Response for Class (RFC) The RFC is the "Number of Distinct Methods and Constructors invoked by a Class." The response set of a class is the set of all methods and constructors that can be invoked as a result of a message sent to an object of the class. This set includes the methods in the class, inheritance hierarchy, and methods that can be invoked on other objects. The RFC for a class should usually not exceed 50 although it is acceptable to have a RFC up to 100. RefactorIT recommends a default threshold from 0 to 50 for a class. If the RFC for a class is large, it means that there is a high complexity. For example, if a method call on a class can result in a large number of different method calls on the target and other classes. It can be hard to test the behaviour of the class and to debug problems since comprehending class behaviour requires a deep understanding of the potential interactions that objects of the class can have with the rest of the system. 2/11/2009 Dr Andy Brooks 12

13 as documented for the RefactorIT plug-in for Eclipse Depth in Tree (DIT) In Java, all classes have java.lang.object as their ultimate super class, which is defined to have a depth of 0. So a class that immediately extends java.lang.object has a metric value of 1. Any of its subclasses will have a value of 2 and so on. DIT is defined in RefactorIT for classes and interfaces as follows: All interface types have a depth of 1 The class java.lang.object has a depth of 0 All other classes have a depth of 1 plus the depth of their super class The deeper a class is in the hierarchy, the greater the number of methods and state variables it is likely to inherit, which makes it more difficult to predict its behaviour. It becomes more specialised and it can be hard to understand a system with many inheritance layers. However, there is a greater potential reuse of inherited methods. If there is a majority of DIT values bellow 2, it may represent poor exploitation of the advantages of OO design and inheritance. RefactorIT recommends a maximum DIT value of 5 since deeper trees constitute greater design complexity as more methods and classes are involved. 2/11/2009 Dr Andy Brooks 13

14 DIT /11/2009 Dr Andy Brooks 14

15 as documented for the RefactorIT plug-in for Eclipse The Dependency Inversion Principle (DIP) The DIP metric calculates the ratio of dependencies that have abstract classes or interfaces as a target to the total amount of dependencies for a class. DIP ranges from 0.0 to 1.0 where 1.0 means that all of the dependencies, the analysed class has, depend on abstract classes or interfaces. Although the DIP states that all dependencies in a program should have an abstract class or an interface as a target, this is usually not going to be the case. Somebody has to create the instances of concrete classes and modules that will depend on these classes. If a concrete class is not going to change much then it is more or less harmless to depend on it. 2/11/2009 Dr Andy Brooks 15

16 <<extends>> <<depends on>> <<depends on>> AirportDialog is an abstract class. Airport and AirportException are concrete classes. The DIP metric value is 1/3 = 0,33. 2/11/2009 Dr Andy Brooks 16

17 as documented for the RefactorIT plug-in for Eclipse LOCM Lack of Cohesion of Methods cohesion/samfesta This is a measure for the cohesiveness of a class (calculated using the Henderson-Sellers method, LOCM-HS). Henderson-Sellers method If (m(a) is the number of methods accessing an attribute A, calculate the average of m(a) for all attributes, subtract the number of methods m and divide the result by (1-m). A low value indicates a cohesive class and a value close to 1 indicates a lack of cohesion and suggests the class might better be split into a number of (sub)classes. 2/11/2009 Dr Andy Brooks 17

18 LOCM HS m( A) m (1 m) Suppose a class has 9 attributes and 9 methods. If each attribute is accessed by only one method, LOCM-HS = 1 If each attribute is accessed on average by five methods, LOCM-HS = 0,5 If each attribute is accessed on average by all nine methods, LOCM-HS = 0 2/11/2009 Dr Andy Brooks 18

19 as documented for the RefactorIT plug-in for Eclipse McCabe's Cyclomatic Complexity (V(G) also known as CC) Introduced by Thomas McCabe in 1976, cyclomatic complexity measures the number of linearlyindependent paths through a program module. This metric is computed as follows: Each function has a base complexity of 1 Each atomic condition adds 1 Each case block of switch adds 1 If V(G) is larger than 10, consider to split the method up. The more complex the program the harder it is to test and comprehend. This metric can additionally be interpreted as the cost of producing test cases for the code. 2/11/2009 Dr Andy Brooks 19

20 // in the beginning: V(G) = 1 // +2 conditions, V(G) = 3: if ((i > 13) (i < 15)) { System.out.println("Hello, there!"); // +3 conditions, V(G) = 6: while ((i > 0) ((i > 100) && (i < 999))) {... } } do not count short-circuit evaluation & // +1 condition, V(G) = 7 i = (i == 10)? 0 : 1; switch(a) { case 1: // +1, V(G) = 8 break; case 2: // +1, V(G) = 9 case 3: // +1, V(G) = 10 break; default: throw new RuntimeException("a = " + a); } 2/11/2009 Dr Andy Brooks 20