One of the nice things about smells is that it's easy for inexperienced people to spot them, even if they don't know enough to evaluate if there's a real problem or to correct them. I've heard of lead developers who will pick a "smell of the week" and ask people to look for the smell and bring it up with the senior members of the team. Doing it one smell at a time is a good way of gradually teaching people on the team to be better programmers.
Some examples of code smells
Conditional Complexity
Watch out for large conditional logic blocks, particularly blocks that tend to grow larger or change significantly over time. Consider alternative object-oriented approaches such as decorator, strategy, or state.
Combinatorial Explosion
You have lots of code that does almost the same thing.. but with tiny variations in data or behavior. This can be difficult to refactor-- perhaps using generics or an interpreter?
Oddball Solution
There should only be one way of solving the same problem in your code. If you find an oddball solution, it could be a case of poorly duplicated code-- or it could be an argument for the adapter model, if you really need multiple solutions to the same problem.
Data Clumps
If you always see the same data hanging around together, maybe it belongs together. Consider rolling the related data up into a larger class.
Indecent Exposure
Beware of classes that unnecessarily expose their internals. Aggressively refactor classes to minimize their public surface. You should have a compelling reason for every item you make public. If you don't, hide it.
Feature Envy
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.
Long method names
Seriously: If you follow good naming standards, long method names are often an indication that the method is in the wrong class. For example,
createWhateverFromWhateverOtherClass(OtherClass creator) vs
creator.createWhatever(). See UsingGoodNamingToDetectBadCode.
Duplicated Code
Balance the smell against the cost of reducing it in your environment. Each environment (language, linkers, etc) has its own threshold for how much duplication you can remove without it being too painful or too obfuscating.
Consequently if a company spent X dollars to develop a product with duplicated code it will have to spend X * K dollars on code refactoring without any single visible improvement of the product, where K is between 3 and 100 depending on skills, complexity, language, etc.
Some companies hire more and more developers to pay interest on that duplication debt or keep changing developers wondering why production emergencies don’t disappear even with best minds on it.
Switch Statements Smell
ObjectOrientedProgramming avoids them: "Most times you see a switch statement, you should consider polymorphism. This is not to say that SwitchStatementsAreEvil, just that they aren't ObjectOriented. Please note also that not all programs that use switches exhibit the CodeSmell.
When you get the SwitchStatementsSmell, it's an indication that your code isn't ObjectOriented. It could also be a case of following the rule DoTheSimplestThingThatCouldPossiblyWork.
Classes with too much code -
See: OneResponsibilityRule, GodClass
Violates the Single responsibility principle of SOLID
Principle of Least Knowledge or Law of Demeter(LOD)
An object should avoid invoking methods of an object returned by another method. For many modern object oriented languages that use a dot as field identifier, the law can be stated simply as "use only one dot". That is, the code a.m().n() breaks the law where a.m() does not.
Ref: https://wiki.c2.com/?SwitchStatementsSmell
https://wiki.c2.com/?CodeSmell
0 comments:
Post a Comment