59

Maybe a little tongue-in-cheek, but as I can't find this answer anywhere through Google, so to ensure Software Engineering has the answer:

What is a helper?

I have seen the name being used everywhere (module names, class names, method names), as if the semantics were deep and meaningful, but in the context of Computer Science (although I don't have a degree in it), I've never seen a description or definition anywhere!

Is it a design pattern? Is it an algorithm? I once worked on a program in which the module and class were both called somethingsomethinghelper (where somethingsomething was fairly generic too) and I promptly renamed it to something that made sense to me, but I feel like I'm missing something here!

3
  • 16
    Helper is what you call something when you don't know what to call it but you know one of its friends. Kind of like calling you 'friend of Zack' instead of Aaron. Double plus ungood.
    – david.pfx
    Jul 9, 2014 at 11:29
  • A helper is any private member, up to isomorphism. Jul 10, 2014 at 4:31
  • 1
    @ThomasEding sorry to come back 3 years later - but I've seen lots of "public" members called "helper", including interfaces. I'd like a source on your definition (the higher quality the better) because that would definitely give me a sense for more code smells.
    – Aaron Hall
    Sep 8, 2017 at 15:13

6 Answers 6

86

A Helper class is a lesser known code smell where a coder has identified some miscellaneous, commonly used operations and attempted to make them reusable by lumping them together in an unnatural grouping. Successive developers have then come onto the project and not realised that the helper class exists, and have consequently rewritten the same common operations, or even created more Helper classes.

But seriously, the main problem with Helper classes is that they are usually operations that act on a specific class, which obviously means in OO terms that they are suffering from an acute case of Feature Envy. This failure to package the behaviour with the data it acts on is why developers so often (in my experience) fail to find it.

In addition to this, as you have already identified SomethingSomethingHelper is actually a terrible name. It is undescriptive, and gives you no real inkling of what sort of operations the class does (it helps?), which also means that it's not obvious when adding new behaviours whether they belong in the Helper class or not. I would break up such classes along the lines of related behaviour that logically group together, and then rename the new classes to reflect what it does.

10
  • 20
    Pretty sure that SomethingSomethingHelper is not the actual name of the class. Whether it's a code smell or not would depend on how specific the helper class is, as helper classes like Math are not a code smell at all. Jul 8, 2014 at 16:58
  • 12
    @RobertHarvey - Enh, most of the ones I've seen have been named SomethingSomethingHelper. Hell, I'm looking at a class right now named HelperMethods in the <company>.Helpers namespace. To me, a Helper class is in the same bucket as *Manager.
    – Telastyn
    Jul 8, 2014 at 18:05
  • 12
    @Telastyn: Perhaps it's an experience thing, then. I've looked through the helper classes in my current project (there are several), and they all have meaningful names. There's only one that's suffixed with Helper, and I think that's to disambiguate it from a class in the .NET Framework having the same name. I'd consider *Helper acceptable if * was something meaningful. HelperMethods is just a failure of imagination; there ought to at least be specific conceptual buckets. Jul 8, 2014 at 18:55
  • 5
    @RobertHarvey - You're probably right. All of my career using modern languages has been cleaning up train wrecks.
    – Telastyn
    Jul 8, 2014 at 19:02
  • 1
    There is a subset of these, called "helper functions", that are actually useful and a good pattern. For example, a common set of lines that would otherwise need to be repeated within a function - one example of where they show up is when you need a do..while loop in Python, which the language doesn't support (see the second example here). Another would be an if/elif/.../else structure, but need to repeat a case at the top and bottom. If possible they should be made local to that function, though, and generally not actually called "helper".
    – Izkata
    Jul 8, 2014 at 21:22
10

A helper is a harmless additional class or method, as long as it complements an external component. When it does the contrary, then it indicates bad design because the code has been excluded from its authority, if there is any authority at all.

Here is an example of a harmless helper, I use a method called FindRep that counts the number of leading zeros.

digits = digits.Remove(0, TextHelper.FindRep('0', digits, 0, digits.Length - 2));

The helper method is very simple, but very inconvenient to copy-paste around and the framework does not provide any solution.

public static int FindRep(char chr, string str, int beginPos, int endPos)
{
    int pos;

    for (pos = beginPos; pos <= endPos; pos++)
    {
        if (str[pos] != chr)
        {
            break;
        }
    }

    return pos - beginPos;
}

And here is an example of a bad helper:

public static class DutchZipcodeHelper
{
    public static bool Validate(string s)
    {
        return Regex.IsMatch(s, @"^[1-9][0-9]{3}[A-Z]{2}$", RegexOptions.IgnoreCase);
    }
}

public class DutchZipcode
{
    private string value;

    public DutchZipcode(string value)
    {
        if (!DutchZipcodeHelper.Validate(value))
        {
            throw new ArgumentException();
        }

        this.value = value;
    }

    public string Value
    {
        get { return value; }
    }
}
2
  • So show me how DutchZipcodeHelper should be done?
    – powder366
    Jun 11, 2020 at 19:59
  • 2
    @powder366 Validate is a private method on DutchZipcode
    – Caleth
    Jul 29, 2020 at 7:55
2

Helper is a commonly used name appendage.

However, it communicates very little about what it does. Every time I have seen it used I have found it to be a suboptimal name.

In fact I consider it to be a code smell that indicates more problems underneath.

Example

Suppose we see the name "WidgetHelper" (here "widget" is a stand-in name for any sort of programmable functionality, and not necessarily a UI widget):

class WidgetHelper:
    ...

What do we learn from the name? We know the object or function does some kind of work secondary to the widget. It is my experience that this might not even actually be true, and one might delete "helper" from the name and improve the communication.

For another possibility, "WidgetHelper" could be wrapping the widget, such that the widget code itself may know nothing about the helper. The implication is that WidgetHelper in this pseudocode example is part of the public API:

class WidgetHelper:
    def __init__(self):
        self.widget = Widget()
        ...

In this case, something like "WidgetAPI" would be a better name, because that, at least, informs the user its relationship to the Widget class. Or perhaps we delete "Helper" from the name and additionally rename Widget to something like WidgetImplementation.

Alternatively, it could be wrapped and called by the widget, implying it is not part of the public API, but rather part of the implementation details.

class Widget:
    def __init__(self):
        self.widget_helper = WidgetHelper()
        ...

Even in this case, with this small amount of information we have an improvement on "helper." It would be more descriptive to call it some generic name like "WidgetImplementation."

"Implementation" may be correct as the implementation may do too much to give it a more precise name. Or it may itself be too vague - this is at the discretion of the namer.

But as we have seen, the name, "helper," doesn't aid in understanding what is going on in the code, other than it is ancillary to the main object of interest. "Helper," could mean many kinds of relationships. Thus, it is overly vague and nebulous, and not well-suited for the purpose of informing the user what the object does.

Conclusion

Naming things is one of the hard problems in computer science.

What is desirable in a name is that it inform the user what the named thing is supposed to do.

But in any case imaginable, it would be more descriptive to use a name other than "helper" or simply remove it altogether.

As a corollary to my experience and this discussion, the choice of "helper" in a name also signals low effort or sophistication on the part of the namer (correctly or not). It is, indeed, a code smell.

Please don't call anything a "helper."

2

It's actually neither.

"Helper" is a collective noun for a group of functions.

A helper is something that works across the project and does a small thing. These guys are often not even organized into a class, they merely extend the functionality or capabilities of the language itself. Here's what I consider a very good example of a helper:

function linesOf($mls) {
    return preg_split('/\s*\n\s*/',trim($mls));
}

This tiny function can have a big impact on how you organize your code (you'll love to put your literal lists in multiline strings) but in itself, it means next to nothing. It's a glorified regex pattern. Still, it makes your code a lot more readable when you say

$a = linesOf('

    apples
    bananas
    cherries

');

instead of its pure regex equivalent.

So that's what helpers are. Tiny tools for generic jobs, not belonging to a specific class. You can force them into one (linesOf could be a method of a string class) but where they really belong is either the global namespace or one static collection of such tools.

Thumb rule: if it's helpful but doesn't seem to belong anywhere, it's probably a helper.

1

Of course "this is a gray area," but my pragmatic experience has been that people invent "helpers" when they have identified some useful-to-them set of common code that they don't want to re-implement. (Some languages refer to these as "mixins.")

The problem is that the common-code is tangentally related to each of the other classes that it might "help." Instead of being some part of a strict class hierarchy, it merely "helps" [all of ...] them. This strategy avoids duplication of source-code but it is not without its dangers.

-2

My company used to use the Base class / Helper class methodology where each object would have two classes. You would have a Person class that contained all of the class properties and definitions and a PersonHelper class that contained all of the methods, SQL statements and Logic that manipulated the Person class. This worked well for us because all of our applications use SQL statements to manipulate data and it was very easy for us to find and modify the SQL statements as needed.

We have since moved on and now put everything in the Person / Base class. We quit using the Helper naming convention because we wanted to have less files in our projects. Also, the length of some of the class names were getting out of control. lol.

Not a great example but you get the idea.

s = CompanyName.PersonHelper.GetPerson()
s = CompanyName.Person.GetPerson()

I'm not saying that using the helper naming convention is the perfect solution but it did work for us for a few years.

4
  • 3
    You didn't explain why. Jul 9, 2014 at 18:00
  • 2
    Yes, I'd like that explanation too.
    – Aaron Hall
    Jul 9, 2014 at 18:11
  • 3
    @AaronHall Consider it a good thing that you do not understand their choice. Jul 10, 2014 at 15:27
  • The usual reason is "Someone thought it was a good idea".
    – gnasher729
    Jul 30, 2020 at 8:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.