Smells to refactoring. Beautiful code continues…

I just found this good resource with a summary of techniques to identify and refactor smelly code.
It’s a good summary of what you get explained with examples and detailed comments in the Fowler’s book.

The original post is at the wiki SmellsToRefactorings

Smells Within Classes

Comments Should only be used to clarify “why” not “what”.
Can quickly become verbose and reduce code clarity.
Long Method The longer the method the harder it is to see what it’s doing.
Long Parameter List Don’t pass in everything the method needs; pass in enough so that the method can get to everything it needs.
Duplicated Code
Large Class A class that is trying to do too much can usually be identified by looking at how many instance variables it has. When a class has too many instance variables, duplicated code cannot be far behind.
Type Embedded in Name Avoid redundancy in naming. Prefer schedule.add(course) to schedule.addCourse(course)
Uncommunicative Name Choose names that communicate intent (pick the best name for the time, change it later if necessary).
Inconsistent Names Use names consistently.
Dead Code A variable, parameter, method, code fragment, class, etc is not used anywhere (perhaps other than in tests).
Speculative Generality Don’t over-generalize your code in an attempt to predict future needs.

This post will be moved to TNW Wiki and Resources area… with the full list.

I had mentioned in another post I found a refactoring tool for VB.NET 2003 at KnowDotNet. I just wanted to thank their developers for saving the VB.NET 2003 community from doing refactoring manually, and special thanks to Les Smith for correcting some problems and giving a fast support.
For those curious about the tool, the url is here

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.