Everyone has seen smelly code that makes you cringe, but some smells are more subtle than others. Developing your code nose to recognize smells is a crucial skill for code craftsmanship. In this session we'll learn how to identify and fix smells like Feature Envy, Shotgun Surgery, and Indecent Exposure. Improve your olfactory perception for sweeter smelling code!
4. Wikipedia says…
• In computer programming, code smell is any symptom in
the source code of a program that possibly indicates a deeper
problem. Code smells are usually not bugs—they are not
technically incorrect and don't currently prevent the program
from functioning. Instead, they indicate weaknesses in design
that may be slowing down development or increasing the risk of
bugs or failures in the future.
20. Bibliography
• Mäntylä, M. V. and Lassenius, C. "Subjective Evaluation of Software
Evolvability Using Code Smells: An Empirical Study". Journal of
Empirical Software Engineering, vol. 11, no. 3, 2006, pp. 395-431.
• Brown, William J., Raphael C. Malveau, Hays W. McCormick, and Thomas
J. Mowbray. Antipatterns: Refactoring Software, Architectures, and
Projects in Crisis. NY: Wiley, 1998.
• Fowler, Martin, Kent Beck, John Brant, William Opdyke, and Don
Roberts. Refactoring: Improving the Design of Existing Code.
Reading, MA: Addison-Wesley Professional, 1999.
• Bock, David, “The Paperboy, The Wallet, and The Law Of Demeter”.
Web. 1 Nov 2013, <http://www.ccs.neu.edu/research/demeter/demetermethod/LawOfDemeter/paper-boy/demeter.pdf>
• Atwood, Jeff. “Code Smells”, 18 May 2006. Web. 1 Oct 2013.
<http://www.codinghorror.com/blog/2006/05/code-smells.html>
Notas do Editor
IntroductionsGround rulesAssess the audience
A code smell isn’t necessarily bad. Meaning, a smell doesn’t mean something IS wrong, just that is MIGHT be wrong and warrants further investigation.
In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem. Code smells are usually not bugs—they are not technically incorrect and don't currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.
The definition we have so far is pretty vague.Part of why I love the term “code smell” is it imparts that sense of subtlety.What smells to me may not smell to you.Developing your “code nose” is a career long endeavor.
So how do you train your nose? Practice!We’ll start by talking about some of the more obvious, smellier smells and work our way “down” to the more subtle.And we’re going to take the same approach to each one.
Ground RulesWhat’s the problem?Why is it a problem?What is the fix?Is the fix worth it?
The worst code smell of all.Why is this bad? Complicates maintenance. May be indicative of green programmers, arch misunderstanding, etcSimilar to Dead Code, Lazy Code, etc.Very rarely is this legit. When could it be legit?
I would not recommend doing an image search for this phrase….What’s the problem?Why is it a problem?What is the fix?Is the fix worth it?
Beware of classes that unnecessarily expose their internals. Refactor classes to minimize their surface area. If you don't have a good reason to make it public, hide it.What’s the problem?Why is it a problem?What is the fix?Is the fix worth it?
What’s the problem?Why is it a problem?What is the fix?Is the fix worth it?
Why is it a problem? Switch Statement might be considered acceptable or even good design in procedural programming, but is something that should be avoided in object-oriented programming. What is the fix?Is the fix worth it?The situation where switch statements or type codes are needed should be handled by creating subclasses
Paging parameters / Format Parameters (XML, json, etc)What’s the problem?Why is it a problem?What is the fix?Is the fix worth it?
What’s the problem?Why is it a problem?What is the fix?Is the fix worth it?
Comments are a smellXML Method comments, inline comments, Commented Code is just plain terribleViolates DRY, and if it doesn’t, you’ve violated something else…Inline comments often means the workings aren’t clear. Make the intent more obvious. When is it okay? Why is it bad? Interface comments – sometimes helpful (e.g. arguments that the method might throw, example usage, etc).Implementation comments – smellComments don’t compile, meaning they can be flat wrong and things still run