You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just curious why something like that is the case. There are a number of instances where the increment operator can be, at the least, jarring. Most obvious example is whether after "y = x++" are y and x set to the same value, but that's just one case of potential confusion and is easily avoided by breaking it into two statements.
And that's the point. When it's an operation all by itself, it's clear. But when it's part of a series of operations, it can hide the meaning of what you're doing. At the base, "increment" and "add one" have the same meaning, but they shift the focus. "increment" hides what you're adding, and focuses on the variable, useful when it's merely a counter or index into a table. But when the variable has a meaning in itself, beyond "counter" or "index," the focus should include what you're adding, how the the state is changing.
A pertinent (but simplistic) example off the top of my head: when rolling internal calendar variables over to the next year, the sequence:
month -= 12; year += 1;
maintains a stylistic symmetry that makes it easier to see at a glance the two operations are related. Switch in the increment operator, you gain no clarity and lose symmetry. It takes you a moment of extra thought to realize the two operations are related. And that difference means you might momentarily lose track of the idea that you're turning a calendar page and have to think about it to remember those two operations are part of a single calendar operation. And every moment where you have to stop and think about the nuances of a statement creates a crack for a bug to slip in. Off-by-one errors, anyone?
In overall usage, the increment operator can be more confusing than other operators (as noted above) so making it the preferred usage seems a little bizarre. Crockford's jsLint, for example, bans them completely. I wouldn't go that far, because there are some cases where their utility outweighs their potential ambiguity, but to force people to use them in all cases is, I think, wrong.
Just curious why something like that is the case. There are a number of instances where the increment operator can be, at the least, jarring. Most obvious example is whether after "y = x++" are y and x set to the same value, but that's just one case of potential confusion and is easily avoided by breaking it into two statements.
And that's the point. When it's an operation all by itself, it's clear. But when it's part of a series of operations, it can hide the meaning of what you're doing. At the base, "increment" and "add one" have the same meaning, but they shift the focus. "increment" hides what you're adding, and focuses on the variable, useful when it's merely a counter or index into a table. But when the variable has a meaning in itself, beyond "counter" or "index," the focus should include what you're adding, how the the state is changing.
A pertinent (but simplistic) example off the top of my head: when rolling internal calendar variables over to the next year, the sequence:
month -= 12;
year += 1;
maintains a stylistic symmetry that makes it easier to see at a glance the two operations are related. Switch in the increment operator, you gain no clarity and lose symmetry. It takes you a moment of extra thought to realize the two operations are related. And that difference means you might momentarily lose track of the idea that you're turning a calendar page and have to think about it to remember those two operations are part of a single calendar operation. And every moment where you have to stop and think about the nuances of a statement creates a crack for a bug to slip in. Off-by-one errors, anyone?
In overall usage, the increment operator can be more confusing than other operators (as noted above) so making it the preferred usage seems a little bizarre. Crockford's jsLint, for example, bans them completely. I wouldn't go that far, because there are some cases where their utility outweighs their potential ambiguity, but to force people to use them in all cases is, I think, wrong.
Edit: I thought I'd seen that before: #16
The text was updated successfully, but these errors were encountered: