This document discusses code smells, which are indications that code may have quality issues that could represent violations of basic programming principles. Some specific code smells mentioned include duplicate code, large methods, and large classes. The dangers of code smells are that they can indicate low abstraction, reduced reusability, and difficulties with testing and maintenance. The document provides recommendations for addressing different code smells, such as extracting methods, splitting classes, and using code analysis tools.

1. Alex .C.Punnen
Code Smells
Alex.C.Punnen

2. Code Smell ?

3. The problem
What is the problem with “smelly” ?
– It could be the indication of a problem
– “Something is rotten in the state of Denmark”
• - Hamlet Act 1, scene 4
– Sometimes there might not be any problem at all

4. Code Smell -The Dangers
Is an indication of a violation of one or more basic
programming principles
– Programming Principles
 The Open /Closed Principle - [wikilink]
• Open for extension,closed for modification (thought of many
as the foundation principle of OOD)
 The Principle of Abstraction-
• Abstracting to reduce duplicated code
 The Liskov Substitution Principle [link]
– Reading -
http://en.wikipedia.org/wiki/Category:Programming_principles
– Being aware is the beginning of the journey to programming salvation....
– Note – For most of these principles the Aha! effect happens when you experience
it in real world

5. Code Smell -Duplicate Code
•Problems
– Update Anomalies
– Hiding of intent
Identical or similar code spread in multiple places

6. What to do -Duplicate Code
•Extract a method
Note -For unit tests a certain amount of code duplication
may be needed, and could be tolerated

7. Code Smell -Large Methods
• A method that does more than one thing., many things,sometimes
unconnected things
•Problems
– Could indicates low levels of abstraction,low level of class
design,reduced re-usability
– Harder to test,poor readability
– http://c2.com/cgi/wiki?TallerThanMe

8. What to do – Large methods
•Split to multiple
methods
•Make the method
do just one thing
...well

9. Code Smell -Large Class
• Okay you split into a zillion small methods and now you have a
large class - http://en.wikipedia.org/wiki/Anti-pattern
•Problems
– Very hard to subclass,extend – kills OCP
– Why did Dinosaurs become extinct ?

10. What to Do ? - Large Class
•A Dinosaur class is created usually when there is no proper design
done
•Pretty easy to create a Dinosaur; don't believe? – watch Jurassic
Park
•Pretty hard to point out the ill effect to programmers who are not
able to understand the concepts of abstraction, interfaces ,virtual
functions and inheritance
•Solution
– Read more ,and do deliberate practice, design and re-factor your
design at least N times. (N inversely proportional to experience)
– Read - http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

11. Other Code Smells
When you become more
experienced, you might have a
tendency to over engineer
– Deep Inheritance hierarchies
with virtual base classes
– Complex frameworks
/generalization where there is
no reuse envisioned
It is knowledge that separates the wise from the rest; the former acutely aware of what they
don't know, the latter acutely aware of what they know.....

12. Code Smell
Programmer - “So how do I.. ? er.. smell it ?
It is easy ! use FindBugs,PMD,Checkstyle & other code analysis
tools or/and integrate and check via SONAR
•Step 1. Find it when you write it !
– Integrate code analysis tools -FindBugs, PMD ,
CheckStyle
– with your IDE – Eclipse/NetBeans
– And/or Cobertura Plugin with Maven
•Step 2. Fix it as you write it.
Industry Best Practice-
On May 13-14 2009, Google held a global fixit for FindBugs tool ..More than 700 engineers ran FindBugs from
dozens of offices. Engineers filed more than 1,700 bug reports, of which 600 have already been marked
as fixed More on the study

13. Author - alex.cp@nsn.com
FindBugs Configuration in Eclipse
Make sure you review and
configure only relevant rules

14. Author - alex.cp@nsn.com
PMD Configuration in Eclipse
Make sure you review and
configure only relevant rules

15. So tell me Connoisseur, how does my code smell ?
Programmer -Okay I have fixed/not fixed things in Sonar,now how ?
Consultant – Okay let me see...

16. So tell me Connoisseur, how does my code smell ?
• If you are aware and still you have chosen, then you would
have a reason
• and if your reasons are right, then,
• You have balanced between reuse and unuse
• Balanced between elegance and purpose
• Balanced between effort spent and value gained

17. That's all Folks
Backup Slides -->

18. Statutory Warnings & License
•Acknowledgment
– Thanks to Wikipedia, Articles in ObjectMentor, C2.com & Google Images
•Advice Warning
– Some of the books which I have put here I have not personally read and
I wont be liable for any monetary damage that you could possible incur by
buying on my advise.
– Some of the advice that I have put here,I have not personally practiced-
at least consciously, but looked like very good advise nevertheless; so
though I could take credit on the mileage you might garner,I wouldn't be
responsible for any adverse ill effects including mental strain and
frustration you might experience in following my advise.
• License
– You are freely allowed (and encouraged) to pass on the advice and use
these slides as long as you put these warnings and acknowledgments in
your slides

19. The Open/Closed Principle
The “Open/Closed Principle” (OCP) was first advocated by Bertrand Meyer
in the first edition (1988) of his book “Object Oriented Software
Construction” and is considered by many as “the most important principle
of object-oriented design.
•Object-Oriented Software Construction is a book by Bertrand Meyer, widely
considered a foundational text of object-oriented programming
 http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction