This document discusses code smells, which are surface indications in source code that typically correspond to deeper problems in the system. It defines several common code smells such as duplicate code, large methods, magic numbers, dead code, and speculative code. The document provides explanations of these smells and recommendations for addressing them, such as extracting duplicated code into methods, breaking large classes into smaller focused classes, and avoiding checking in experimental code. It notes that code smells often arise from issues like haste, apathy, and ignorance when developing code.

1. Code Smells
and other
Malodorous
Software Odors
Clint Edmonson
clint@polarissolutions.com

3. We need to talk…

4. Code Smell
Code smell, also known as bad smell in computer programming
code, refers to any symptom in the source code of a program that
may contain an area of concern.
According to Martin Fowler, "a code smell is a surface indication
that usually corresponds to a deeper problem in the system".
https://en.wikipedia.org/wiki/Code_smell

5. Code Sleuth
• A smell is by definition something that's quick to spot - or sniffable
• Smells don't always indicate a problem
• The best smells are easy to spot and most of time lead you to really
interesting problems
• 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
Martin Fowler
https://www.martinfowler.com/bliki/CodeSmell.html

6. Prepare your
sniffers…

8. Low Value Comments
Comments that don’t enhance understanding of the code.
Comments add value when:
• They describe the purpose of the code (why), not the what or
how
• Explain the steps in an algorithm

10. Dead Code
Large blocks of code commented out and/or methods and classes that
are left in the code but no longer used in favor of newer functionality.
Dead code makes it harder to understand and maintain the system.
Quick fix:
• DELETE IT!
• If we ever want to see it again, we can look it up in source control
history.

12. Marathon Methods
If it’s more than a screenful, its too much!
Some guidance:
• A method should have AT MOST 10-12 steps
• Extract large blocks into their own methods
• You will OFTEN find duplicated code
• A good looking method should look like the steps in a recipe
book

14. Magic Numbers & Strings
Hard coded numbers and string values inside methods.
Generally based on an assumption or implicit knowledge and frequently duplicated
in multiple places.
Very susceptible to fat-fingering errors.
Remedies:
• Refactor to enums and use implicit conversions to ints or strings when
absolutely needed
• Consolidate down to static and read-only class fields and properties
• Strive to make the application data driven through a config or settings component

16. Duplicate/Triplicate Code
Code fragments that look almost identical.
Could occur when multiple work on a code base and are unware of existing code
that could be used or refactored to be re-used.
Also occurs in haste when trying to meet a deadline and unable to resist the
temptation to copy and tweak a working class or method.
Advice:
• Refactoring is NOT something you do later! You are making things worse.
• ALWAYS use the Red-Green-Refactor cycle when coding
• You are a professional developer - make sure the code you are checking in is the
BEST work you can do and you would be proud to show someone else.

18. The Blob Class
Lots of methods and properties, making the code difficult to read,
understand, and troubleshoot.
Often indicates that the class contains too many responsibilities.
Remedies:
• Can the large class be restructured or broken into smaller
classes?
• Use the Class Responsibility Collaborator (CRC) card exercise
to discover a better OO model

20. Speculative Code
Tutorial, experimental or research code checked into the production
code base.
Code semantics are frequently different from the problem being
solved.
Advice:
• If you are exploring a solution or learning a new technique, do it in a
blank project or private branch until you are satisfied that it solves
your design problem
• Re-implement it in the production code base using intent-driven
development

22. Not Invented Here (NIH) Syndrome
Code that re-invents the wheel. Pursuit of an interesting problem
trumps the needs of the project.
The right thing to do:
• Leverage well known, documented frameworks
• Avoid creating your own Rube Goldberg machine

23. Stack Overflow
Programming
Trusting someone else’s code
to solve your problem without
truly understanding how
and/or why it works.
Solution:
• Practice intent-driven
development
• Code with intent and purpose
• Understand EVERY line of
code you write

24. And many, many more…
Wikipedia
• https://en.wikipedia.org/wiki/Code_smell
Sourcemaking online lessons
• https://sourcemaking.com/refactoring/smells
Smells to Refactorings
• http://www.industriallogic.com/wp-
content/uploads/2005/09/smellstorefactorings.pdf

25. Homework Assignment
• Solution Sprawl
• Leaky Abstraction
• Inappropriate Intimacy
• Indecent Exposure
• 7 Layer Cake
• Uncommunicative Name
• Inconsistent Naming

26. Where do these smells
come from?

27. Primal Forces
• Haste – sacrificing integrity for expedience
• Sloth – making poor decisions based on the “easy” answer
• Apathy – not caring about solving known problems
• Narrow-mindedness – refusal to practice widely-known solutions
• Avarice – putting own intellectual pursuits above the needs of the
problem at hand
• Ignorance – failing to seek understanding before solving a problem
• Pride – inventing new designs when existing solutions could readily
be applied (NIH syndrome)

28. What do we do about them?

29. //------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
//
// Changes to this file may cause incorrect behavior and
// will be lost if the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

30. Don’t be a tool!
Practice
Intent Driven Development!

31. Thank You!
Clint Edmonson
clint@polarissolutions.com
Drop by the booth or visit us online at
https://polarissolutions.com