x += 1 in readable code

[Mark J. Reed]

First, I simply don't agree with the statement that "x += 1" is a rarity
in readable code. But that's not something we can measure without an
objective measure of readibility, so let's move on.

However, to address the specific example, I would just use each_with_index:

> counter = 0
> array_of_stuff.each {
> |element|
> if elementIsScrewy(element)
> raise "Whoa, element is screwy! #{element.inspect}, " +
> "look for the problem #{counter} elements into the page"
> end
> result = doSomethingWithElement(element)
> ...
> counter += 1
> }

array_of_stuff.each_with_index {
|element, counter|
if elementIsScrewy(element)
raise "Whoa, element is screwy! #{element.inspect}, " +
"look for the problem #{counter} elements into the page"
end
result = doSomethingWithElement(element)
...
}

[Ben Giddings]

On Saturday, July 19, 2003, at 02:11 PM, Mark J. Reed wrote:

> However, to address the specific example, I would just use
> each_with_index:
>

Right, but my point was that I didn't really want to touch the iterator
because the index part was just a temporary hack to get some debugging
info. The goal was to change the code in such a way that when I found
the source of the problem I could nuke a few lines and the code would
be the same as before. Aside from the ease of "ctrl-k" or "dd"
(depending on your editor), it also makes it easier to spot the change
if you do a diff against the original.

It was a weak attempt to come up with a situation where x += 1 was
useful. Any other times when it is handy? I use iterators all the
time, but I also find myself using x += 1 all the time (though offhand
I don't remember when).

I'm on the fence about x++. I use it all the time in other languages,
and it would save some keystrokes when I wanted to do the equivalent
thing in Ruby. I agree it could cause problems if someone tried to do
0xDEAD++, but 1) it should be easy to write a parser to catch that and
2) someone who does that is really odd and deserves whatever they get.
On the other hand, right now if you are modifying an object, the method
either has an equal sign in it, or has a bang in it. This would be yet
another special case. Maybe instead Fixnum should have a #succ! method?

Ben

[Mark J. Reed]

On Sun, Jul 20, 2003 at 03:33:43AM +0900, Ben Giddings wrote:

> On the other hand, right now if you are modifying an object, the method
> either has an equal sign in it, or has a bang in it.

That's not universaly true. There are several methods in Ruby that
modify the receiver even though there's no ! or = in the name.
I'm having trouble thinking of examples, but Array is full of them -
push, pop, shift, unshift, << . . .

-Mark

[Brian Candler]

On Sun, Jul 20, 2003 at 03:33:43AM +0900, Ben Giddings wrote:

> It was a weak attempt to come up with a situation where x += 1 was
> useful. Any other times when it is handy?

The only time I can think of is when counting things for a summary report:
e.g. number of 'good' or 'bad' items seen, number of things changed etc.

> I'm on the fence about x++. I use it all the time in other languages,
> and it would save some keystrokes when I wanted to do the equivalent
> thing in Ruby. I agree it could cause problems if someone tried to do
> 0xDEAD++, but 1) it should be easy to write a parser to catch that and
> 2) someone who does that is really odd and deserves whatever they get.
> On the other hand, right now if you are modifying an object, the method
> either has an equal sign in it, or has a bang in it. This would be yet
> another special case. Maybe instead Fixnum should have a #succ! method?

But then you would be asking for the number itself to be changed, not the
variable which contains the reference.

As far as I know, x.<anymethod> always leaves variable 'x' pointing at the
same object. Mutators mutate objects, not variables. However, x += 1 always
leaves 'x' pointing at a *different* object.

x = 1
x.succ!

would be the same as

x = 1
1.succ!

which is meaningless.

Regards,

Brian.

[Tim Hunter]

On Sun, 20 Jul 2003 03:33:43 +0900, Ben Giddings wrote:

> On Saturday, July 19, 2003, at 02:11 PM, Mark J. Reed wrote:

>> However, to address the specific example, I would just use
>> each_with_index:
>>
>>

> Right, but my point was that I didn't really want to touch the iterator
> because the index part was just a temporary hack to get some debugging
> info. The goal was to change the code in such a way that when I found
> the source of the problem I could nuke a few lines and the code would be
> the same as before. Aside from the ease of "ctrl-k" or "dd" (depending
> on your editor), it also makes it easier to spot the change if you do a
> diff against the original.
>
> It was a weak attempt to come up with a situation where x += 1 was
> useful.
> Any other times when it is handy? I use iterators all the time, but I
> also find myself using x += 1 all the time (though offhand I don't
> remember when).
>
> I'm on the fence about x++. I use it all the time in other languages,
> and it would save some keystrokes when I wanted to do the equivalent
> thing in Ruby. I agree it could cause problems if someone tried to do
> 0xDEAD++, but 1) it should be easy to write a parser to catch that and
> 2) someone who does that is really odd and deserves whatever they get.
> On the other hand, right now if you are modifying an object, the method
> either has an equal sign in it, or has a bang in it. This would be yet
> another special case. Maybe instead Fixnum should have a #succ! method?
>
> Ben

Fixnum#succ! has come up before. Do a google groups search on it.

Personally I don't use x++ even in C. My reason? Changing the value of a
variable is important enough that we should spend some visual weight on
it, and x++ doesn't deliver as much impact in code as x += 1. (I think of
it as having more pixels, or ink.)

There's only one place I use x++, and that's in the 3rd expression in a
for statement. It's a common C idiom and doing anything different would be
confusing.

As for the pre-increment and both flavors of decrement, forget it. The
pre- and post-increment/decrement operators are only there because the
machines on which C originally ran had INC and DEC machine instructions
and it was easy to get the compiler to generate them. They're a remnant of
the old days.

[Mark Wilson]

On Saturday, July 19, 2003, at 07:32 PM, Tim Hunter wrote:

> [snip]

> As for the pre-increment and both flavors of decrement, forget it. The
> pre- and post-increment/decrement operators are only there because the
> machines on which C originally ran had INC and DEC machine instructions
> and it was easy to get the compiler to generate them. They're a
> remnant of
> the old days.

As it happens, I was just reading Dennis Ritchie's history of C, at

[url]http://cm.bell-labs.com/cm/cs/who/dmr/chist.html[/url]

and he says the following about the reasons for the increment/decrement
operators:

"Thompson went a step further by inventing the ++ and -- operators,
which increment or decrement; their prefix or postfix position
determines whether the alteration occurs before or after noting the
value of the operand. They were not in the earliest versions of B, but
appeared along the way. People often guess that they were created to
use the auto-increment and auto-decrement address modes provided by the
DEC PDP-11 on which C and Unix first became popular. This is
historically impossible, since there was no PDP-11 when B was
developed. The PDP-7, however, did have a few `auto-increment' memory
cells, with the property that an indirect memory reference through them
incremented the cell. This feature probably suggested such operators to
Thompson; the generalization to make them both prefix and postfix was
his own. Indeed, the auto-increment cells were not used directly in
implementation of the operators, and a stronger motivation for the
innovation was probably his observation that the translation of ++x was
smaller than that of x=x+1."

Regards,

Mark

[Ben Giddings]

On July 19, 2003 07:32 pm, Tim Hunter wrote:

> Personally I don't use x++ even in C. My reason? Changing the value of a
> variable is important enough that we should spend some visual weight on
> it, and x++ doesn't deliver as much impact in code as x += 1. (I think of
> it as having more pixels, or ink.)
>
> There's only one place I use x++, and that's in the 3rd expression in a
> for statement. It's a common C idiom and doing anything different would be
> confusing.

As for me, I use it all over, but:
1) I only ever use it as the 3rd argument of a for loop or on a line by
itself, and never assign the result of it to anything
2) I only ever use it for integers, never for pointers or anything where it's
not 100% clear that what's happening is that a number is going up by one.

In fact, whenever I'm porting/editing code someone else has written I always
remove any potentially confusing pre/post increment operators as I go.

> As for the pre-increment and both flavors of decrement, forget it. The
> pre- and post-increment/decrement operators are only there because the
> machines on which C originally ran had INC and DEC machine instructions
> and it was easy to get the compiler to generate them. They're a remnant of
> the old days.

Well for me, because I only ever use it as a complete, isolated expression, I
could use either pre-increment or post-increment and be happy.

But, having said that, I really like using them in those really isolated ways.
To me "i++" and "i += 1" are very different. One is incrementing the number
i, the other is adding i and 1 then assigning the value of that addition to
i. Now those all boil down to the same thing, but from years of using i++,
whenever I see i += 1 I have to look at it carefully before I am convinced
that it's just incrementing a number.

I'm not convinced that Ruby should change to suit my idiosyncracies. If i++
becomes available, I'll use it happily. If it doesn't, I'll learn to be
happy with i += 1.

Ben