Demystifying the Long Arrow "Operator"

Some Dood on November 30, 2018

I recently stumbled upon some code that I found to be really interesting. It essentially iterates over a loop but with a twist. It uses the myste... [Read Full]

That is just a bad idea.

There really is no such thing as a "Long arrow" operator.

The example of:

while (i --> 0) {

Is really just:

while (i-- > 0) {

The post decrement does not belong to the greater than sign, and implies entirely different things.

Exactly the point I tried to hit on. I purposefully added quotation marks around the word "operator" every time I used it in the context of the "long arrow operator" because of that.

But that is the problem. There is no such thing as a "long arrow operator", and you are just sowing confusion.

I see. I get your point. I wrote this article so that people would be aware of an unorthodox way of formatting their code, so that when they encounter them in the wild, they'd be prepared to tackle them.

Indeed, the entire point of this article is to demystify something that doesn't exist. It's great that you pointed this out, though.

Nah, keep it up. The confusion was sown long before that. I had a good laugh.

Oh. Thanks, man. Appreciate it! ๐Ÿ‘

but you also called it analogous to a limit function. which is confusing and it's just not. limits in my mind are inclusive, infinite sequences, not integer-based, step-wise functions that forget their initial value.

That's true. I do catch your drift. I see where I might have caused some confusion there.

It isn't meant to equate the two ideas, though. One shouldn't get too worked up in it. It is just an analogy after all.

i think the issue is that it's a bad analogy. it draws parallels where there are none, and it creates a mind map that just doesn't match the terrain.

That's true. This isn't the first time I've made bad analogies. Guess I'm still learning how to play with my words in an interesting manner. I'll keep working on it.

Admittedly, though, I don't see the analogy I made as entirely wrong. There is still some truth to it. The notation does imply some sort of "approaching by decrementing" to an extent. Regardless of that, it's still a bad analogy, as you said, and I agree.

However, I won't edit the article because that's really how I thought about the notation at first. It would really be dishonest of me and to myself if I changed the analogy now. So for now, it shall serve as a reminder to me to be better with my analogies.

The notation does imply some sort of "approaching by decrementing"

i think the issue is that "approaching by decrementing" just isn't a limit. if you'd stumbled across a "approach through an infinite sequence" operation (maybe something that recursively takes smaller steps as it approaches a correct answer?), then i think you'd be on to something.

seems like an excellent way to frustrate the hell out of future maintainers. the formatting is weird and the value you declared for your index is never used. that's subtle and unexpected (two things you should never be striving for in code meant to be read by humans).

The value for the index is used, it is just used in a confusing way.
This whole article is just an example of what NOT to do.

Also, realize that the post decrement actually happens AFTER the comparison to zero, which might not be obvious to someone as well. As you say, don't do this with code that someone else might have to maintain.

i should clarify, the problem that stood out to me is the initial value of the index is never used in the body of the loop. that's what makes this thing so awful. the loop "works", but then you're left chasing an off-by-one error.

Well, the point of this article isn't really to encourage you to use it, thus my recommendation against it towards the end of the article. It's just a fun way of reading code.

In the bright side, at least you now know what that weird long arrow means in some code bases if ever you encounter them.

Come on, you don't discourage it nearly enough as you should if that was indeed your intention. This isn't something that "beginners shouldn't be doing", this is something that no one should be doing. Saying something isn't "for beginners" isn't condemnation, it's just motivation for aspiring ninjas. There's no upside to using this "operator": Long Arrow "operator" considered harmful.

Don't worry. I'm pretty sure the comments section has discouraged its usage strongly enough. It's fascinating how passionate everyone is against the way of formatting such code.

In 12 years of the programming, I first hear about "long arrow" operator. It confuses beginners.
But you can do the same, in easy way:

let x = 2
while (x--) { 
// 1
// 0

Watch out with that notation though, it's best to only use it on integers declared as a constant.

let x = 2

// Wait, you have to pay taxes over your loops!
x *= 1.1

while (x--) { 
  console.log("Nothing can be said to be certain, except death and taxes")

You need to know what you are doing with your code.

Certainly! But with Javascript not having an int type, it can lead to unexpected bugs.

Sometimes the space between the declared variable and the loop fills up with other code, especially in a project that's not squeaky clean to begin with.
Or the variable was passed in as an argument to a function, and eventually someone calls the function with unexpected input.

Maybe a coworker wants to loop over something in batched chunks, and naively divides x by a chunkSize.

Assuming that x in while(x--) is an integer which will hit zero isn't necessarily bad, just something to be careful with.

It's true that it is dangerous.
I see a reason to use tools (approaches) in related situations.
Construction without zero only in the case, when you know what you do. For example, iterate through array elements from the end:

const arr = ["this", "is", "c", "h", "a", "r"]
let n = arr.length
while(n--) {
  const el = arr[n]

or count input value as a number. In this case, input can be any, the function must know the type and cast to it. If float โ€“ make it as int by parseInt or Math functions.

Yup, that's definitely true. In cases when one has to decrement until any number other than 0, I think the long arrow "operator" has its... "uses".

let i = 10;
while (i --> 5) {

Nowadays decrement and increment are bad practice. Consequently operator "long arrow" will be disappeared, and it's good.

Looks beautiful with my font ligatures!

Kewl Kode

Oh, what's that? A reverse long-arrow operator? Read about it here!

This article is a much needed resource for someone who might come across such usage and google it. I agree that it shouldn't be used because it relies on whitespace formatting and in fact, deceives the reader into thinking it's a single legitimate operator.

I suggest adding names of languages that accept this usage in the title? And perhaps a clarification in the beginning that the "long arrow operator" doesn't actually exist.

I'm sure the comments section have clarified those facts strongly enough. ๐Ÿ˜‚

That's why everyone should avoid increment (++) and decrement (--) operators

As in the Douglas Crockford's Javascript: The Good Parts, he writes:

++ and --
The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by
encouraging excessive trickiness. They are second only to faulty architecture in enabling to viruses and other security menaces. There is a plusplus option [in JSLint] that prohibits the use of these operators.

Definitely can't disagree with the Great Crockford.

Creative! I love weirdness like this.

The only problem with it is that it requires reeducation. And people really resist being educated.

Perfect for a pet project. Not so much for your employer's source.

You'd just have to add some docs to explain what this funky thing does.


Thanks! I'm glad you share my fascination with weird things. *high five*

it's not really a "reeducation" problem so much a bad code problem. it might be useful for code golf, but it's just a confusing way to decrement an index.

Never saw it before, wouldn't recommend using it. Too much of a "wow this is a clever trick" thing which doesn't do much more than harm readability (not criticizing the author here, I think he's acknowledging exactly this).

"long arrow is a bad idea" seems to be a common theme in most of comments.

Knowing that it's a bad practice makes this post worth reading ๐Ÿ˜€

And love your avatar & the featured image๐Ÿ˜

Thanks! I'm glad you liked them (the post and my avatar).

People truly have strong opinions on best practices, don't they? ๐Ÿ˜

You're welcome ๐Ÿ˜Š

People truly have strong opinions on best practices, don't they?

Those opinions make'em heard and let us learn from each other ๐Ÿ˜›

But why? I don't see how this can be useful at all O.o So please don't make this as an actual thing.

Oh, for sure! You share the same sentiment as everyone who read this article (including me). ๐Ÿ˜‚

I just wanted to show that there is an unorthodox way of writing two separate operators. That way, when one encounters such code in the future, they'd be ready to tackle it.

I think its pretty dumb and extremely funny :D

Did you mean nuisances or nuances? Maybe both?

This is a total click bait title. Dismistifying something that doesn't exist. ๐Ÿค”

Aren't all "mysteries"? ๐Ÿ˜‰


I believe I hit on that point pretty explicitly in the article. Somewhere around here, I think?

I'm reasonably sure that prettier fixes this so that its not an issue.

Never combine post/pre increment/decrement with other operators. It makes code hard to understand and can lead to nasty bugs. That's why many langs like Python don't have them at all.

Tha'ts why everyone should avoid increment (++) and decrement (--) operators:

code of conduct - report abuse