Software Engineering CS3003 Lecture 4 Code bad smells and refactoring

2 Structure of this lecture This lecture will answer the questions: What is refactoring? What are the benefits of refactoring? What are Code Bad Smells?

What is refactoring? ‘The process of changing a software system in such a way that it does not alter the external behaviour of the code, yet improves its internal structure’(Fowler et al 1999) Does not change behaviour and user should not notice any difference Constant regression testing important Is a form of preventative maintenance Important in an XP environment as code changes frequently 3

actor.html actor.html 4

Refactoring Start with an existing code base and improve the internal structure. For example:  Reduce duplicate code  Improve cohesion, reduce coupling  Improve understandability, maintainability, etc. Fowler et al 1999 suggest:  22 Code Bad Smells – bad structures in code  72 Refactorings – how to eliminate CBSs 5

How do you do refactoring? Fowler says refactoring is not something you should dedicate two weeks every six months to…rather, you should do it as you develop. Refactor when you:  recognize a warning sign (a “bad smell”)  add a function  fix a bug  do a code review (as part of constant pairing)  The third time you change a piece of code need to refactor Many tools support refactoring, e.g. Eclipse, NetBeans Problem automating many code bad smells. 6

Some example refactorings… See for full list (maintained by Fowler) Extract Method void printOwing() { printBanner(); //print details System.out.println("name:" + _name); System.out.println("amount" + getOutstanding()); } Refactored to… void printOwing() { printBanner(); printDetails(getOutstanding()); } void printDetails(double outstanding) { System.out.println("name:" + _name); System.out.println("amount" + outstanding); } 7

What are Code Bad Smells? de-smells.html de-smells.html 8

Code Bad Smells 1. Duplicated Code: Same code structure happen in more than one place. 2.Long Method: A method is too long. 3.Large Class: A class is trying to do too much, it often shows up as too many instance variables. 4.Long Parameter List: A method needs passing too many parameters. 5.Divergent Change: Divergent change occurs when one class is commonly changed in different ways for different reasons. 6.Shotgun Surgery: Shotgun surgery is similar to divergent change but is the opposite. Every time you make a kind of change, you have to make a lot of little changes to a lot of different classes. 7.Feature Envy: The whole point of objects is that they are a technique to package data with the processes used on that data. A Feature Envy is a method that seems more interested in a class other than the one it actually is in. 8.Data Clumps: Some data items together in lots of places: fields in a couple of classes, parameters in many method signatures. 9.Primitive Obsession: Primitive types are over used in software. Small classes should be used to in place of primitive types in some situation. 10.Switch Statements: Switch statements often lead to duplication. Most times you see a switch statement you should consider polymorphism. 11.Parallel Inheritance Hierarchies: Parallel inheritance hierarchies is really a special case of shotgun surgery. In this case, every time you make a subclass of one class, you also have to make a subclass of another. You can recognize this smell because the prefixes of the class names in one hierarchy are the same as the prefixes in another hierarchy. 12.Lazy Class: Each class you create costs money to maintain and understand. A class that isn't doing enough to pay for itself should be eliminated. 13.Speculative Generality: If a machinery was being used, it would be worth it. But if it isn't, it isn't. The machinery just gets in the way, so get rid of it. 14.Temporary Field: Sometimes you see an object in which an instance variable is set only in certain circumstances. Such code is difficult to understand, because you expect an object to need all of its variables. 15.Message Chains: You see message chains when a client asks one object for an other object, which the client then asks for yet another object, which the client then asks for yet another object, and so on. Navigating this way means the client is coupled to the structure of the navigation. Any change to the intermediate relationships causes the client to have to change. 16.Middle Man: You look at a class's interface and find half the methods are delegating to this other class. It may mean problems. 17.Inappropriate Intimacy: Sometimes classes become far too intimate and spend too much time delving in each others’ private parts. 18.Alternative Classes with Different Interfaces: Classes are doing the similar things but with different signatures. 19.Incomplete Library Class: Library classes should be used carefully, especially we don't know whether a library is completed. 20.Data Class: These are classes that have fields, getting and setting methods for the fields, and nothing else. Such classes are dumb data holders and are almost certainly being manipulated in far too much detail by other classes. 21.Refused Bequest: Subclasses get to inherit the methods and data of their parents, but they just use a few of them. 22.Comments: Don't write comments when it is unnecessary. When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous. 9

Duplicated Code Bad Smell “Number 1 in the stink parade!” (Fowler) Often the result of cut and pastes –very dangerous. If the same expression is in two methods in the same class make it a private routine and parameterize it (Extract Method refactoring) If the same code is in two related classes put common code into closest mutual ancestor and parameterize 10

Long method Bad Smell Short methods very important for:  Understanding  Making correct changes A sign that trying to do too many things Break up into smaller private methods within the class (Extract method) Often a comment indicates the next major step so this is a good point to “break it up”.  When you see a comment, make a method. 11

Comments Bad Smell “Comments can be used as deodorant” to hide CBS Fowler claims that comments are a sign of:  opaque, complicated, inscrutable code.  code that is in need of explanation but that actually needs restructuring rather than commenting. Fowler advocates:  self-evident coding practices by making methods short and identifiers long  Commenting the decision making process for the solution implemented. 12

13 Reading for the week Sommerville ed9 Chapter 9 Refactoring: Improving the Design of Existing Code, Martin Fowler(et al.), 1999, Addison- Wesley Comments on module so far…