Updated February 2, 2021
Document Document Document
When it comes to JS coding, you’re not documenting just for your own sake, but for that of others as well. Following standardized structure and naming conventions is great. It’s a fundamental coding 101 type of thing. But documenting your code is more – it’s not self-documenting, so please don’t think about that as a possible solution.
Check out JSDoc for information on best practices in documenting your code.
If you’ve not had to look back on code written some time ago, you’ll be surprised how little of it you may remember quickly and how clever you were in doing things with complexity as if they were no-brainers.
Use Hungarian Notation
Variable naming ranges from the incomprehensibly simply “a1”, “nvqz” to the TMI (too much information) of “loopOneCounterForDOBReCalculationDuringCheckout”. Instead of going either direction too far, consider amending your variable naming using a one character prefix bit of trickery.
With Hungarian Notation, you add an “s” for string, “b” for boolean, “o” for object, etc, so as to give greater clarity as to what you’re working with, giving you instant insight into variables like “sFirstName”, “oSchool”, or “bIsGraduate”.
Don’t be Afraid of Frameworks
Spend enough time around other developers and you’ll undoubtedly have friends in two camps. On the one side will be the “purists” who advocate doing everything from scratch without help from libraries, frameworks, IDE code editors or the like. They’ll edit with vi editor and have created their own repository complete with thousands of home-grown functions.
The other side are those who will spend three hours figuring out how to use the latest, and bulkiest, frameworks to code something that should have taken 10 minutes and been done in 20 lines of code.
Don’t let either side sway you from looking at frameworks for some situations and ignoring them for others. There’s a time and a place for using, and not using, frameworks.
One additional consideration is to look at using frameworks or libraries already included in the platform with which you’re working. For example, WordPress is including jQuery straight out of the box. If you’re picking a library, or framework, that’s already a part of the platform, you won’t incur any performance penalties by leveraging that which is already being included anyway.
Look at Lean Framework Alternatives
React, jQuery, Angular, Vue and others all have lightweight alternatives. It pays to check for lean alternatives before doing all the coding because you’ll want to know how well the alternatives provide functional equivalents before going too far down one path or another.
Don’t Use Globals
Unfortunately, variables and functions with global scope can run into conflicts when multiple files make use of them in different ways. If the variable you thought was going to contain one bit of information is included by scripts loaded after the one you’re working on, you’ll find the results unexpected at best and dangerous at their worst.
The moral of the story is simply don’t use globals.
Use Development Environments for Development Work
It’s so easy to just login and make a quick tweak to some code on the “live” server instance. After all, it’s only a one line change and you know exactly what needs to be done. Unfortunately, those quick and dirty changes are also the times when you’re most likely to introduce a typo, leave out a semicolon or some other hurried mistake that can cause your main production website to become non-functional, costing you time and money.
For many seasoned coders, a development environment runs locally or on a low-end spec hosting account which then feeds into a staging environment. Staging servers then feed the production environment and is where code changes are tested.
Take the time to isolate your changes from the live server. Make sure everything works as intended and then deploy onto the live production environment once you’re 100%.
Use Asynchronous Requests
The user experience benefits. Page speed benefits. In fact, there are very little downsides to using AJAX whenever possible. The moral of the story? Use asynchronous request/response whenever possible and appropriate.
Let CSS Do what it Does Best