soledad penadés

A few weeks ago (or was it a few days ago? ahhh, holidays) I had my code reviewed by a colleague, who suggested I replaced all appearances of

if(whatever.length === 0) {

with

if(!whatever.length) {

I said I preferred to just leave it as it was, as I found it easier to scan visually. I find the strict comparison with zero highly stands out when you're reading code, which is what we most often do as programmers.

What I didn't also express is that there is a certain cognitive dissonance when I see the if(!whatever.length) part. It sounds like "if whatever has not length, then..." which is not what I want to express, and is also distracting: "what do you mean if it has length, can it not have length, and why should I be worried about that?"

Or also, if you're not familiar with precedence rules, you might wonder if it's applying the NOT operator to whatever itself. Why would we do that? What would that mean? It's confusing.

I don't want people unfamiliar with coding to agonise over my intentions. I want them to look at the code and immediately go: "oh, so we want to know if there is something in this array. We want to know if it's empty, therefore we want to know if it has zero elements, so we'll look at its length property".

That's it.

There's another reason why I don't like to use this style and it's the lack of consistency it engenders. Suppose you want to look for whether the array is empty, whether it has exactly one element, or whether it has more than one, at different points in the code. So you might end up with something like this:

if(!array.length) {
  // if it's zero
}

// ...

if(array.length === 1) {
}

// ...

if(array.length > 1) {
}

We are enquiring about the same thing all the time: the amount of items in the array. But we are doing it in slightly different ways. This is, again, very confusing, both when you're new to programming and when you're tired, because you have to make an argument of why using one versus the other, and those are mental resources you'd better spend solving your actual problem. Better be consistent and use the same style everywhere. You'll be just "wasting" a few characters, but gaining a lot of time. And code uglifiers can take care of compressing your code to the very minimum, anyway.

Moreover: using truthy values such as in this case feels like the ghost of C code past*, where boolean didn't exist as a data type until very recently, so all boolean-like values were held in integer-typed variables, and anything with a value of zero evaluated to "false" and anything not zero was "true". That gives way to code like this:

file = open("todo.txt", O_WRONLY);

if(file) {
  /* we could open the file */

where if the todo.txt file can be opened, the file variable will hold a bigger than zero value representing the file descriptor, and hence it will be "true".

But not everyone that comes to JavaScript has a C background, so I fear that each time I am "clever" and use one of these I am making it harder for new people to use or learn from my code.

Since I am sufficiently convinced that I am clever, I don't need to demonstrate it by writing pseudo-obscure code constructs. So I'd rather use my cleverness to write code that is crystal clear and expressive :-D

* will you excuse the BAD PUN?