The wonderful [[Refactoring Guru]] says code can stink, and therefore categories bad code into the following stinky categories: # Bloaters Chunks of code that have become too large to work with. - Long Methods - any method longer than ten lines should make you start asking questions - Large Classes - Primitive Obsession - sometimes using class and objects is better than adding spatial meaning to a primitive - Long Parameter List - You should not have more than 3 or 4 params - Data Clumps - Similar groups of primaries popping up around your code should be replaced with a class # Object-Orientation Abusers Incomplete or incorrect application of object-orientation. - `Switch` statements and `if` chains - Temporary fields - Fields that get their values only under certain circumstances, and are otherwise empty - Refuse bequest - Subclasses that only use a small portion of the methods of their superclass - Alternative interfaces - Class that do essentially the same thing, but use different names for their methods # Change Preventers When changes to one spot must be propagated out to changes in others. - Divergent Change - When many changes are needed to a single class in response to a change - Shotgun Surgery - When a single change is needed across many classes in response to a change - Parallel Inheritance Hierarchies - When a new subclass for one classes causes the need for new subclasses in other classes # Dispensables Something pointless whose presence makes the Code clunkier and/or slower. - Comments - [[Great Code Doesn’t Need Comments]] - Duplicated Code - Lazy Class - classes that don't do enough to justify their existence - Data Class - a special case of a lazy class wherein the class only exists to hold data (and not modify it) - Dead Code - Unreachable or orphaned code - Speculative Generality - [[YAGNI]] # Couplers Excessive coupling between classes. - Feature Envy - when class A operates on the data of class B more than class B does - Inappropriate Intimacy (woof bad name) - Accessing private fields or methods of another class - classes should know as little about each other as possible. - Message Chains - When the same sequence of calls happen often and repeatedly - modifications within the chain can become chain-breaking - I request A, A requests B, B requests C... - Middle Man - When class A's only job is to delegate work to class B, why does A exist? - Note: if class A exists _for an articulable reason_ then it's worthwhile - examples such as [[Code Design Patterns|Proxies or decorators]] # Other Smells - Incomplete Library Class - You access a library, it does _most_ of what you need, but not everything - and you cannot change it. **** ## Source - [[Refactoring Guru]] ## Related