The HelperIsaCodeSmell page may provide some insight.
I delve through the code base as I prepare to maintain. I notice the use of functions and macros, classes and defines peppered throughout the code. They may be a class, in a function, or aNameSpace, and it is not descriptive: it is a 'helper'. Helper is a CodeSmell. You don't understand the problem, only that the solution in its current form requires help. A suggestion: choose a more helpful name.
The coup de grace comes when those enamored by the patterns movement find themselves smitten with helpers -- snippets of code who do nothing on their own and barely something when composed -- and suggest they are grand pieces of an architectural puzzle: proxy-helper-singleton-visitor; pub-sub-impl-pimple-lightweight-provider. Understand the problem better and describe better the solution. Choose better names; helpers are not helpful! </rant> +1. Classes whose names end in Helper are a particularly noxious odor. What kind of "help" do they provide, exactly? What do they *do*? Names should be chosen carefully, to descriptively reveal what is is abstracted, what is done, what the intent is. Calling something a "Helper" is lazy. Having said that, I caution that there's nothing inherently wrong with respecting the patterns movement; it has contributed much knowledge to the profession. But the real wisdom is in knowing when to use and not use a given pattern. Inexperienced architects over-use patterns, because they think doing so is sophisticated and/or makes them appear so. Experienced architects, on the other hand, use ContextualSense. Having said that, thanks, ranter, for sharing "impl-pimple". That's pretty damned funny. Can I have permission to use that? :) --RandyStafford I understand the sentiment, but I also find plenty of places where the "helper" seems to be the best-smelling option (usually due to other language smells). In one Java program, for instance, I needed to add some new behaviors for lists. I needed to be able to add this functionality to lists of multiple types, and often returned from code I don't control. The way I handled it was to create a ListHelper ? that delegates to a base list object, plus adding other useful methods. I toyed with other names and implementation ideas before realizing I couldn't identify one that would be any less smelly. - SteveJorgensen I would suggest then that helper is a sign of unnecessary abstraction in an over-complicated design. Or perhaps it is just a sign that we need more languages with MixIn or Category support (like Scala or ObjectiveCee ) where new methods can be added to already existing classes without doing inheritance Name or Idea? Is this a complaint against helpers in general, or the use of the title "helper"? If I am not mistaken, the name is a RubyOnRails convention. Perhaps that is why you see it more. However, I am not sure if it has a formal definition or consistent industry meaning. Where I work the idea and name are inseparable. I have, however, at my own expense started groundbreaking on a refactoring: whereby the helpers become slaves. In all seriousness, any name that carries with it the connotation of "helper" has been (in my experience) flawed. Helpers take the form of algorithms or data structures. If I am looking over a codebase, the algorithm or data structure name is a more concise (and ultimately meaningful) form of communication. I think Helper is both a pattern and a smell depending upon context. In a situation where your project is connected to a lot of code that your team does not own or maintain -- whether it comes from other teams within the organization or from other organizations -- the preferred MoveMethod refactoring is obstructed, so the method has to live somewhere else. DelphiLanguage explicitly supports this sort of thing with its 'helper' keyword. I'll try writing this up as a HelperPattern to see if my thoughts hold water. -- JeffreyHantin See: DesignPatterns , HelpersInsteadOfWrappers , MaintenanceProgrammer Categories: CategoryRant , CodeSmell