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.)


    showHelpMessageIfInvalid : function(c, e, h) {

    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) {


    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) {

// Helper method with long names (that get in the way?)
higherLevel : function(component, event, helper) {

// Helper method with short names (that help?)
higherLevel : function(c, e, h) {

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

  • 1
    We can use c, e, h and inside the helper methods instead of passing the the helper we can do var h = this; and again in the helper we can access with the same name h; May 17, 2018 at 2:35

3 Answers 3


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.

  • Great points as usual. It's a sad situation where when you want to re-use a fragment of code in other helper methods that references to it need to be qualified. And h. is less intrusive than helper.. I'll likely work on "if you can convince your team to use c, e, h as a rule" so that at least it's a company convention for our managed package components.
    – Keith C
    May 17, 2018 at 5:13

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.

  • 1
    Thanks I appreciate the feedback. My thoughts is as the context is clearly Lightning Components, what c, e and h mean is within that context.
    – Keith C
    May 16, 2018 at 20:02

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.

  • Thanks for answering. I agree that for new people the full names help and for a couple of years have been using the full names. Wondering now though if shorter is better (in the same way that modern programming languages generally favour compact language mechanisms over verbose ones).
    – Keith C
    May 17, 2018 at 5:20
  • I think that's the rub, the maintainers of Lightning Components by virtue of being in the walled garden of Salesforce is very, very mixed bag. Barrier for entry is really low and you get a lot of non-programmer thinking and resources doing development. If you're in a situation where you may be rotating resources or you yourself roll off, verbosity is better IMO.
    – tsalb
    May 17, 2018 at 6:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .