is a strategy for code smell assessment long overdue.pptVIP

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) 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 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 Thanks for listening! Code smells, slice-based metrics and plenty of deodorant????????? Steve Counsell Brunel University Alessandro Murgia University of Cagliari  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 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 Commonly-studied smells (cont.) Feature Envy Remedied (deodorised) by ‘moving’ the method to the c