Code smells, slice-based metrics and plenty of deodorant

1. Code smells, slice-based metrics and plenty of deodorant Steve CounsellBrunel University Alessandro MurgiaUniversity of Cagliari

2. Introduction • Code smells are areas of code which “scream out” to be refactored • In theory, a code smell would be indicative of a decaying class • Methods becoming longer • Classes becoming bigger • Coupling becoming greater • Cohesion deteriorating

3. Commonly-studied smells (cont.) • Feature Envy • “A classic [code] smell is a method that seems more interested in a class other than the one it is in. The most common focus of the envy is the data” (Fowler) • God Class (aka Key Class) • A class that is deemed to have grown too large • Long Method • A method that is deemed to have grown too large • Long Parameter List • Method is deemed to have too many parameters

4. Commonly-studied smells (cont.) • Feature Envy • Remedied (deodorised) by ‘moving’ the method to the class where it is most needed • God Class • No obvious remedy • Extract class? • Long Method • Remedied by splitting the method into at least two • Long Parameter List

5. What we did • Premise • Smell-based classes will have low cohesion • We used Eclipse • Jdeodorant • Allows smell extraction from Java systems • Slice-based metrics plug-in (Tsantalis et al.): • Overlap • Tightness • Coverage (omitted from this analysis for clarity – honestly!)

6. Overlap and Tightness (function F) Overlap(F) = Tightness(F) =

8. ) = 0.74 ( Overlap = + Tightness = = 0.58

9. Study 1 – Evolizer

10. Evolizer tool • A tool for studying the evolution of OO systems • Developed at the University of Zurich • 300 classes/interfaces • We looked at the following smells: • God class • Long method • Feature envy

11. God class • The JDeodorant tool found 18 occurrences of the God class • For each of the God classes • We extracted the two slice-based metrics for all methods in those classes: • Overlap • Tightness • Abstract classes/interfaces an issue

12. God class - problems • Constructors were often the largest methods in a God class (metrics n/a) • Single line methods with no local variables were a frequent occurrence (metrics n/a) • Get and set methods • Single variable methods • Use of ‘super’ to access a superclass

13. Low cohesion values are not apparent

14. Tightness and Overlap (Counsell et al 2010)

18. Long method • The JDeodorant tool found 9 occurrences of Long Method • For each of these methods: • We extracted the same two slice-based metrics for all methods in those classes • Overlap • Tightness

19. Long method - problems • Constructors were often the largest methods (metrics n/a) • Single line methods with no local variables were a frequent occurrence (metrics n/a) • Get and set methods • Single variable methods • Use of ‘super’

20. Low cohesion Values not apparent

22. Feature envy • The JDeodorant tool found 11 occurrences of Feature envy • For each of these methods: • We extracted the two slice-based metrics for all methods in those classes

23. Feature envy - problems • ………same problems as with the other two smells

26. A hypothesis • In terms of cohesion, we would expect: • Long Method to contain the most un-cohesive methods • God class to contain the next most un-cohesive methods • Feature envy to be the most cohesive

27. A hypothesis – result mean values • For Overlap: • God class most cohesive • Feature envy • Long method least cohesive • For Tightness: • Long method most cohesive • Feature envy • God class least cohesive • Most values of Overlap and Tightness > 0.5

28. Study 2 – Proprietary System

29. Background to Study 2 • C# sub-system for a web-based, loans system providing quotes and financial information for on-line customers • We examined two versions of one of its sub-systems: • an early version, comprised 401 classes • later version (version n) had been the subject of a significant refactoring effort to amalgamate, minimize as well as optimize classes • Comprised 101 classes only

30. Smell analysis • We focused on three smells which, arguably, should be easily identifiable from the source code: • God Class • Long Method • Lazy Class. A class is not doing enough to justify its existence, identified by a small number of methods and/or executable statements; it should be merged with the nearest, related class

31. God Class • We found many god classes to be architectural pattern-based class (Page Controller and Data Transfer Objects) • Should be left alone, irrespective of the cohesion value • They also had relatively large amounts of coupling • So eradicating this smell would not only be unwarranted, but difficult (because of the coupling)

32. Long Method • Class ComparisonEngine.cs contained the method with the highest number of statements. • Inspection of the code revealed this method to contain one large switch statement comprising 340 statements • Deodorising this method would be a major undertaking • Often ‘long’ methods are a necessary part of the implementation of an architectural pattern • Leave them alone • Found evidence of these features in both start and end versions

33. Conclusions • Many problems with extracting the Weiser set of metrics and interpretation in OO • Use of parameters might be a better bet • Use of variables in any cohesion metric is subject to various problems • Decision on eradication of smells (deodorant) is a problem • Might explain the difficulty of capturing cohesion

34. Thanks for listening!