Naming conventions for component, event, helper parameters in Lightning Components?

Question

Examples variously call the component component or cmp but there are so many references to the component or event or helper in typical code that I'm thinking it's time to reserve the single letter names for these as follows.

(One precedent is Android's R class.)

Controller:

({
    showHelpMessageIfInvalid : function(c, e, h) {
        h.childOf(c).showHelpMessageIfInvalid();
    },

    checkValidity : function(c, e, h) {
        var child = h.childOf(c);
        if (typeof child.checkValidity === 'function') return child.checkValidity();
        else return child.get("v.validity").valid;
    },

    focus : function(c, e, h) {
        h.childOf(c).focus();
    },
})

Helper:

({
    childOf : function(c) {
        return c.find(c.get("v.multi") ? "dualListbox" : "select");
    },
})

Here is another example from an internal discussion about what the code looks like when a method is decomposed into calls to other methods:

// Apex or Java
void higher(String argument) {
    lower1();
    lower2(lower3(argument));
}

// Helper method with long names (that get in the way?)
higherLevel : function(component, event, helper) {
    helper.lower1();
    helper.lower2(helper.lower3(component.get(“v.argument")));
}

// Helper method with short names (that help?)
higherLevel : function(c, e, h) {
    h.lower1();
    h.lower2(h.lower3(c.get("v.argument"));
}

What naming convention have you adopted in your Lightning Components for these parameters?

Answer 1

The default values are component, event, and helper. It's in most (all?) of the documentation, and all of the default templates I've seen (e.g. when making a new controller). Some people shorten it to cmp, evt, and hlpr or something, but I don't see any good reason for that, given that we have decent autocompletion in most IDEs and we're not restricted to an arbitrary code size like we are in Apex. Legibility should be the primary concern, not saving a few characters. Every time I see someone write "cmp", I kind of cringe a little. It looks very amateurish.

For me personally, however, I will use the c, e, h convention for code that will never see the light of day. For example, I write a few components a week in pursuit of solving questions here on SFSE. The actual prototype code will likely just be c, e, h just to see if it is feasible. I also write a lot of mockups before I make full, production-ready components. Since they're not "real" versions, they use div/span instead of lightning:whatever, and they use c, e, h as the standard parameters, and most of the variables are only 2-3 characters long anyways, but I only ever use c, e, h, i, t/x as single-character variables, and they always have a specific purpose and will never, ever mean something else in my code.

For code that is destined for a managed package, and I'm the sole developer, I would also likely use c, e, h paradigm until/unless another person needed to see the code. On a larger team, I would request that we make a stand and agree on a convention, which would probably result in the use of component, event, and helper, since those names help facilitate newer/less experienced developers. It would have probably been nice if Salesforce had started those three characters as a convention, because then everyone would use them, but we have to live with the design choices that were given to us.

However, if you can convince your team to use c, e, h as a rule, and spread the rule to others, then one day that may well be a reality, one that I would welcome with open arms. There's no point in having a variable 9 characters long that is used in every single controller method when one would suffice. The only great thing is that we're not locked in to a specific value, so we can start using it today. One thing I would avoid doing, however, is mixing the two; either update all your code, or don't bother.

Answer 2

To be honest I would extremely advice against using single letters for the component/event/helper.

Single letter is a sign for local variable. Eg: i for iteration. I agree that those 3 are referenced a lot but making them single letters in my opinion makes code less readable.

Maybe because I was touching a lot of languages and technologies I'm opposing such naming convention.

For example single letter e means for me exception. Single h is header. Only single c for me could mean component.

To summarize if its parameter and its not local I would use more descriptive names.

Component -> cmp, Event -> event, Helper -> helper.

Additionally IDEs will autocomplete them most of the times.

Answer 3

I only deal with lightning components now and found it much easier to always stick to component, event, helper in their full format. I find that shortening it obfuscates unnecessarily for new lightning devs (and there will be many incoming). I even use make of _self as the variable reference in my helper class instead of this just so there's no doubt what it's doing.

Lightning is already confusing enough to start with, so readability is paramount IMO.