Although it's very common to use shortened variables, I think code should be as readable as possible and reduce any factor for confusion.
For example:
function handleAction (e) {
// what is e?
}
In this case, e probably means event or error, but why not just name it as such to remove confusion?
function handleAction (event) {
// oh ok, so now we can do this:
event.preventDefault();
}
Granted we could give the function a better name, like handleLinkClick() or something similar, but this is a simplified example and there are many other cases where being exact with variable names could clear any confusion. I try to do this everywhere else to stay consistent, such as loops:
books.forEach((book, index) => {
// do something with book and index...
});
In more complex code, I might name it bookIndex to make it even clearer.
What do you think about this approach? I really would love to know how many other developers do this, or is shorter code still preferred?
I try to be descriptive as possible, but I use “evt” instead of “e” and “pos” or “ind” instead of “i”. If I’m looping in a 2D array, forget it, my iterators will be row and col instead of j and k.
It depends.
In most code, I want to be as descriptive as possible. Any other developer should be able to read through the code and understand my intentions. And there shouldn’t be any ambiguity about what purpose a variable serves. Are we iterating over results? Great. Call the loop index “resultIndex”.
There’s usually also code that can be used in a lot of contexts, maybe implementing some basic algorithm or a tiny piece of business logic. Maybe it’s even just a single line function. In that case, I stick to a,x, and y as parameters and I,j,k as iterates to emphasize how generic the code is meant to be.
I would rather have event than e. It's more descriptive and don't have to flinch for a second (even at a subconscious level) to know what it means.
I personally prefer variables to be as descriptive as possible. But that being said, if you have a linter that forces lines to be of a certain length, then having single letter variables like e ,i and so forth seems more viable.
A rule of thumb (something that I had picked up from another developer I had worked with) is that variables names need to get more descriptive the further they are used from the point of initialization. 😄
I prefer to use the event.preventDefault() most of the time because is more descriptive, and sometimes you have to show your code to your project manager or someone who doesn't understand these abbreviations that are so common between us. In the end, most of the code go through Uglify, and the length of the variable name is not an inconvenient in production.
Same goes for the index vs i. Let's say I just want to use the index as key for my React components, I use it as i, but if I have to do any other operation with it, I will go for a more descriptive name.
Remember that you read as much code as you write, and it has to be as friendly for you as it is for the machine ;)
"i, j, k" has been pretty much standard for iterators in C syntax languages -- which JavaScript, PHP, and a host of others are -- since 1972. If you do not recognize what those are for, you're probably in the wrong business. For some reason Pascal programmers will use "t, n, v" -- never found out why...
If it's a event callback, you KNOW what it's being passed, again why waste time saying event.
Whilst I do like verbose code, you have to draw the line at where you go from clear to just plain obtusely pedantic. It's the opposite of where some people go so cryptic you can't figure anything out, mistaking over-the-top obfuscation for being 'concise'.
So long as the practice is standard (i, j, k) or obvious (event on an callback for an event handler), I don't see the problem with it.
At the same time, "handleAction" is a nice big word, but VAGUE. If you called it "eventHandler" or "eventCallback" you wouldn't need to explain "e". Sometimes it's not about making everything verbose, it's about making the vague obvious in a manner that explains everything else!
Though minimizing the impact of variables like 'i' can be fun in JavaScript... check this out:
var allInputs = document.getElementsByTagName('input');
for (var i = 0, input; input = allInputs[i]; i++) {
input.disabled = true; // for example
}
As valid nodelist entries would never be loose false, it works... isolating our "cryptic" iterator variable to the "for" line. We wouldn't even need it inside the loop. I actually use this method a lot.
Gergely Polonkai
You have to believe in things that are not true. How else would they become?
I usually go the middle route:
idxandevt.They are still short enough not to type much when using them, but long enough to be obvious and not to freak out linters that require a minimum identifier name length.