Naming conventions for component, event, helper parameters in Lightning Components?
Examples variously call the 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 is au ranaming conventions have you adopted in your Lightning Components for these parameters? What is naming convention in Salesforce?
Naming convention in Salesforce is a rule to follow as you decide what to name your identifiers like class, variable, constant, method, etc. But, it is not forced to follow. So, it is known as convention not rule. Naming conventions make the application easier to read and maintain.
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.