Despite seeming like one of the simpler aspects of programming, proper variable naming can have some of the greatest impacts when producing code that won’t induce hair ripping emotions in several months’ time.
To keep your hair intact:
- Camel Case – This is where the capitalisation of the words look like a camel’s humps, for example, myFancyVariable. We always want to keep the first letter as a lowercase, not only does this help readability but in Lightning Web Components failure to do so can cause us issues when referring to them in HTML!
- Be descriptive – think about what the purpose of this variable is and the data it holds, this should be your first port of call when choosing a name.
- Keep it simple! – If you’ve followed the previous point, you might be tempted to make a super long variable name such as contactsBelongingToAccountArray. We can immediately tell what the purpose of this variable is, but we could write this in a simpler way, such as account contacts. Not only is no information lost here, but it’s also far easier for us developers to quickly read and quickly type.
- Maximum of 3 capitals in a row – This one is purely from a readability point of view. Having more than 3 capitals in a row, especially for abbreviations, can make it really difficult to quickly glance at a piece of code and read its name. For example, HTTPRequest is more difficult to take in than HttpRequest.
While these bullets may seem simple, mastering them is a very difficult skill. Don’t be afraid to ask a friend or colleague to double-check your names after you’ve written them, it’s a great way to practice!
You might be thinking, “right now I understand variable naming so I should just apply the same to functions, right? Functions are just variables that do something after all” and you’d be right!
For functions, we want to follow the same basis as variable naming, but with an additional aspect thrown in. Our function names should start with an action eg submitForm. This makes it much easier at a glance to identify a function and draws a mental separation between functions and variables, especially when you’re passing functions around as variables in callbacks!
Aura and Lightning Web Components (and by extension Visualforce and the wider web) run on two different methodologies for sending and receiving events. These are traditional events (component events in Aura) and Publisher Subscriber events (Application events in Aura). While the end result is the same, they have fundamental differences in how they’re made and how they should be treated.
Traditional Events (Component): These events are used to communicate in a Child -> Parent manner and are highly predictable in nature. They should be named entirely in lowercase (eg on right-click). You attach them to components and can prevent their propagation if somethings not quite right (eg stop submitting an invalid form)
Publisher Subscriber events: Used when we want to communicate with sibling components – avoid using these where there is a child -> parent relationship. Requires custom code to handle the communication and firing of event responses – take a look at this trailhead for a great starting module). Handlers must unsubscribe when done – failure to do so can lead to unforeseen consequences when a component reacts to an event after it is no longer required to do so.
Example of a traditional event in a Lightning web component – This event could be handled with an on clicked event handler.
Comments in code are a hotly debated topic, with people saying you should add as many as possible and others saying they should be avoided entirely. In reality, the best practice is somewhere in between.
- Whenever you are writing a block of code you should ask yourself three questions: Are my variables and functions well named? Is there some outside context required? If I was drunk, could I understand this?
If you answer no to any of the above three questions, a comment may be a good idea! Now then, that comment should just reiterate what’s going on in the code, that’s a bit pointless since we could just read that, instead, it should be a simple description of the why behind the code, not the what. To put it another way, a good comment describes why something is the way it is and isn’t just a description of what is there.
It’s super important to remember that we don’t write code for the computer to understand, we write it for our fellow humans, so keeping everything nice and clear without any ambiguity is key to writing good code.
Curly braces have a love-hate relationship with programmers, some love their verbosity and explicitness and others hate them for being too verbose!
Sticking debug statements into our code is a really useful development and debugging tool for us developers while we are producing solutions. Sometimes it’s really useful to print something about our code to review at our leisure.
While there is nothing wrong and is actually encouraged, with included debug statements while we develop, these should be removed from any code that goes into a production environment (NodeJs is an exemption to this!). Sticking details about the inner workings of our code in an easily accessible format opens up the opportunity for somebody with nefarious intentions to get a good glimpse into how our components work, and how to exploit them.
For example in Google Chrome, it’s trivial to modify the code of Aura components on a page and our debug statements may provide inspiration for an attack vector. Let’s keep things safe and use the browser’s debugging tools and breakpoints when in production (or use a custom logged if you’re feeling fancy!).
Another nugget of advice when using debug statements is to only log primitive values – so Strings and Integers, rather than objects as a whole. Without getting into the technicalities behind this, logging objects to the console creates a reference to the object that was logged.
This means that the garbage collector (the thingy that clears up memory) will see a reference to the object and keep it around, wasting potentially valuable RAM! As Well as that, in Aura components, it can prevent the component from being destroyed, keeping all of its event handlers active, those Application events powering your component can easily create a headache when they fire for no apparent reason due to a ghost component haunting you!
By Alexander Crisp, Salesforce Developer – connect with him!