List of Code Smells
- Identical or very similar code exists in more than one location
- Can use 'Extract Method' refactoring
- A method, function or procedure that has grown too large
- Good naming of method is a key over here
- Instead of comment, add method with name explaining intention of the code
- Look for conditional and loops expressions
- When a class is trying to do too much, it often shows up as too many instance variables, sometimes call as 'God' object
- Check if few attributes can be segregated as another component or another subclass
- For GUI class, you may need to move data and behavior to a separate domain object
- A long list of parameters in a procedure or function make readability and code quality worse
- In object oriented programs, parameters list tend to much smaller than procedural language
- If possible, remove parameter(s) and let receiver invoke method(s) to get values by itself
- Encapsulate parameters in an object (if make sense) and send the object as parameter instead
- It occurs when one class is commonly changed in different ways for different reasons, e.g. changing multiple methods on every introduction of financial instrument
- If, over time, you make changes to a class that touch completely different parts of the class, it may contain too much unrelated functionality. Consider isolating the parts that changed in another class.
- If a change in one class requires cascading changes in several related classes, consider refactoring so that the changes are limited to a single class
- When the changes are all over the place, they are hard to find, and it’s easy to miss an important change
- Methods that make extensive use of another class may belong in another class. Consider moving this method to the class it is so envious of
- You spot it when you constantly see the same few data items passed around together
- Start and end are a good example of a data clump that can go as Range object
- Often data clumps are primitive values that nobody thinks to turn into an object.
- Primitive Obsession is the name of a code smell that occurs when we use primitive data types to represent domain ideas
- Example - using string to represent a message or telephone number, integer ro represent an amount of money
- The problem with switch statements is essentially that of duplication. Often you find the same switch statement scattered in different places
- The object-oriented notion of polymorphism gives an elegant way to deal with it
- Apply strategy pattern instead of using switch statements
- In this case, every time you make a subclass of one class, you also have to make a subclass of another
- Example is if some business object (e.g. inventory) need to represent in HTML, PDF, Printer, it might be case of having different views objects, so if another business object need to be added, all these classes need to be created again
- Not everyone feel it to be bad smell though
- A class that does too little
- It might be a class that was added because of changes that were planned but not made
- A class that isn't doing enough as it has been downsized with refactoring
- Write code to solve today's problem, and worry about tomorrow's problem when they actually comes
- Follow YAGNI - You (Probably) Aren't Gonna Need It
- Remove abstract classes that are not doing much
- Unnecessary delegations can be removed
- Methods with unused paramters should be removed
- An object in which an instance variable is set only in certain circumstances
- Example - Occurs when a complicated algorithm needs several variables and implementor avoid huge parameter list. In this case, extract the method and its variables in different object.
- Watch out for long sequences of method calls
- Example - A.getB().getC().getD().getTheNeededData()
- If a class is delegating all its work, why does it exist?
- Refactor classes that are merely wrapper around other classes
- It describes a method that has too much intimate knowledge of another class or method's inner workings, inner data, etc
- Change bidirectional association to unidirectional
- In case of inheritance, subclasses are going to know more about their parents than their parents would like them to know
- If similar classes have differences in their interfaces, client will differ in how they interact with each of the classes
- Use rename method on any methods that do the same thing but have different signatures for what they do
- Occurs when responsibilities emerge in our code that clearly should be moved to a library class but we are unable or unwilling to modify the library class to accept these new responsibilities
- Introdue foreign method or local extension
- Classes with all data and no behavior
- Ask what behavior should be in this class and move that behavior
- If you inherit from a clss, nut never use any of the inherited functionality and override it differently then the question is should you really be using inheritance?
- Whe you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous
- A good time to use a comment is when you don't know what to do.
- Comment is good place to say why you did something
Comments
Post a Comment