Hungarian naming conventions were not always evil

As a Salesforce developer, used to working in Apex the lack of strong typing in Javascript can be a challenge.

Without the compiler to tell us about type errors in our code, it’s really useful to have coding conventions that help us to spot errors. Even with typing, it helps to keep everything you need to know about a line of code close to that line.

And this was the original point of Hungarian naming of variables – we include some information about what the variable is, in the name. This doesn’t necessarily have to be the type, but it could be if that is helpful.

Getting the naming right makes code obviously correct or incorrect. For example, we could adopt a convention for Lightning Component controllers which need to call an Apex method: the variable for the action must be the name of the Apex method, appended with the word ‘Action’ e.g.

var getAccountAction = component.get(‘c.getAccount’);

//… lots of code setting up the callback

$A.enqueueAction(getAccountAction);

By choosing the name ‘getAccountAction’ for our variable, it is obvious that we are doing the right thing when enqueue it later on. You don’t need to scroll back up through the code to find out which Apex method we are calling, or that the object we are passing in is, in fact, an Action that we can enqueue. We know, by convention, that it must be.

And if we were ever to read:

var loadAccount = component.get(‘c.getAccount’);

Then, we would immediately see that we have broken the convention. The names don’t match and ‘loadAccount’ doesn’t end in Action.

So, in both places, we can spot errors within a single line of code rather than having to remember lots of context or go hunting for information elsewhere.

Joel on Software is great, and well worth reading the full article for more about this

This business of making wrong code look wrong depends on getting the right things close together in one place on the screen.