Helper Function

Functions have two main purposes: aiding code reusability and breaking down a task into smaller logical units. Functions that do not aid code reusability are helper functions; their sole purpose is to "help" a single function by cleaning the code and making the logic clearer. The opposite of a helper function is a library function, which focuses on code reuse.

Helper functions are often very concrete as each one is used in a small section of code. On the other hand, library functions are very abstract, allowing them to be used in multiple projects.

If a function is only used a single time, it is probably a helper function.

From the below quote, it appears that what I call a library function, others call a helper function. -Michael Lombardi

From  AreLongAndDescriptiveRelated : In my book, a function that is called more than ten times in a program is almost certainly a "helper" function.) I and my friend, we do not, because the longer the names of "helper" functions are, the less they "help"...

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

转载于:https://my.oschina.net/yongbin45/blog/65094