Vivek Agarwal’s Portal/Java Blog

An IBM Gold Consultant’s weblog about IBM, Lotus, WebSphere, J2EE, IT Processes, and other IT technologies

Dusting off the “Bad Smells in Code” presentation!

Posted by Vivek Agarwal on June 7, 2008

Recently, I dusted off a presentation (i.e. re-skinned and reused) that I had done back in year 2000 about “Bad Smells in Code” that was derived from Martin Fowler’s book Refactoring: Improving the Design of Existing Code. While the Refactoring book itself was a little too prescription oriented for my liking, the chapter about code smells was very good in my opinion. I look upon code smells as fairly common classic mistakes made in developing code that you are best advised to avoid – they are usually indications that something is not right in paradise and needs a closer look, and possibly some refactoring (i.e. clean-up) is in order. This blog entry focuses on object-oriented code smells.

What is a code smell?

A code smell identifies classic mistakes made in developing code. These mistakes typically result in code that is difficult to understand, maintain, debug, and extend.

What are some common code smells in object-oriented code?

Duplicated code

  • The worst stinker of all!

Long method

  • Difficult to reuse and difficult to understand.
  • The object programs that live best and longest are those with short methods.
  • The best object programs are endless sequences of delegation. Their payoffs are explanation and sharing.

Long parameter list

  • Hard to understand, methods become inconsistent and difficult to use and more likely to require change.

Uncommunicative name

  • Does the name of the method succinctly describe what that method does?
  • Could you read the method’s name to another developer and have them explain to you what it does? If not, rename it or rewrite it.

Inconsistent names

  • Pick a set of standard terminology and stick to it throughout your methods.
  • If you use “add”, then use “add” in all relevant situations – not “create”. Another example is “delete”/”remove”.

Inappropriate intimacy

  • Classes delving into each other’s private parts.
  • Excessive use of class A’s accessors from class B.
  • Over intimate classes need to be broken up as lovers were in ancient days! 

Indecent exposure

  • Beware of classes that unnecessarily expose their internals. You should have a compelling reason for every item you make public. If you don’t, hide it.

Large Classes

  • Too much code
  • Too many instance variables
  • Use layering and decomposition to avoid this problem.

Classes with too little code 

  • Often data classes that can become domain classes
  • Or candidates for downsizing!

Divergent change

  • A class is commonly changed in different ways for different reasons
  • Example – database + functionality

A large number of function classes

  • Indicate that the designers are thinking upside-down, i.e.. thinking of that which can be done to an object rather than that which can done by the object.

Feature envy

  • A method that seems more interested in a class other than the one it actually is in.
  • Many messages to the same object from the same method

Data clumps

  • Data items often hang around in groups together.
  • Extracting them into a class of their own will help reduce field lists and parameter lists.

Switch statements

  • Leads to duplication which leads to shotgun surgery
  • Consider polymorphism instead.

Speculative generality

  • Planning for change that never occurs
  • Increased complexity

Too many casts

  • Over generalization


  • Often used as a deodorant for stinkers
  • Superfluous comments

There are other smells too but these are the most important ones in my opinion.


To summarize, code smells give you an indication that there is trouble in paradise. They are only a guideline and cannot be used as absolute directives. When you realize that you are writing code that reeks of one of these smells, then STOP and ask yourself if you proceeding down the right path. If not, REFACTOR.

If you have the time, take a look at How to Design a Good API & Why it Matters – this presentation by Joshua Bloch is relevant even if you are not into designing APIs and all you do is design/code!

It was good to write about OOD – a topic that is near and dear to my heart, but one that I look into much too rarely with all the things on my plate. And presenting on this topic to some new team members was good too – wanted to emphasize some of my key coding philosophy points to them, and code smells act as a good introduction. I will be back later with my “code smelling exercise” that I used during this presentation to make my points about code smells. 🙂

5 Responses to “Dusting off the “Bad Smells in Code” presentation!”

  1. malcolm said

    this is all very good stuff!! i was wondering if you’re still doing anything with Liferay?

  2. Vivek Agarwal said

    Thanks for the comment!

    Yes, my team continues to work with Liferay Portal for various client engagements. I do keep in touch with Liferay development/releases, as I think they have a good thing going there. However, personally I just dabble in a lot of different things from an architect perspective – I did download Liferay Portal v5 and run it to see what is new and how well it works.

    If you are interested in using a reputed, knowledgeable, systems integrator do feel free to contact me at vagarwal at xtivia dot com. We have consultants who know what they are doing and can lend immediate value.


  3. […] by Vivek Agarwal on June 21, 2008 Sometime back, I wrote on Bad Smells in Code that were defined as – “A code smell identifies classic mistakes made in developing code. […]

  4. Srihari Konakanchi said

    good tips, it would be more obvious if can explain through some code snippets for each scenario!

    – Srihari Konakanchi

  5. […] […]

Sorry, the comment form is closed at this time.

%d bloggers like this: