For Each Anomaly

[Stephen Barncard]

You shouldn't be shocked by this. In many 
languages I've worked with (including HC and 
BASIC), it's not usually cool to change any loop 
variable directly, but instead one must work from 
a copy. Pretty standard practice for years.  One 
can easily use another variable instead. To you 
it's just a variable, to Rev it's a 'thingie' 
that needs to be managed. When you 'go behind a 
language's back' strange stuff can happen.

Don't touch loop variables. End of story.

from:
http://blogs.msdn.com/alfredth/archive/2007/03/19/programming-proverbs-12.aspx

Programming Proverbs 12: Leave loop variables alone
Another way of expressing this is to use loop as 
if they were read-only constants. Loop variables 
should be initialized and changed only in the 
loop statement itself.

The problem with doing it anywhere else is that 
it is too easy to either make the modification 
incorrectly or to do so in the wrong place.
Changing loop variables outside the loop 
statement also makes programs more difficult to 
debug and to modify. debugging gets complicated 
when one has to search for the locations where a 
variable is modified. Modifications to loop 
variables should only happen in one place to keep 
it simple. By treating loop variables as 
read-only and never modifying them inside the 
loop the debugging process is simplified at least 
a little. Sometimes every little bit helps.

A lot of beginners think that once they are done 
with a program that it will never be revisited. 
That may be true for programs that are created as 
class assignments but it is generally not the 
case for most any other programs.

Students should always write their programs as if 
someone else will later come along to either 
maintain or enhance it. It's a good habit to get 
into as it forces better design practices. When 
it comes to maintaining or more importantly 
adding code to a loop the last thing you want is 
problems figuring out where and how the loop 
control variable is modified.
Keeping it simple (like leaving loop variables 
alone) is a good idea and a good habit to teach.


>
>This is looking completely wrong at the issue. A 
>variable should be changeable, it's in the 
>definition of the name. If a variable is not 
>changeable it should be renamed to "constant" or 
>maybe "don'ttouchthisthingy". If a user changes 
>a variable, it should not throw errors, or 
>behave unexpected. Most people have enough 
>problems with expected behaviour, no need to 
>complicate the matter.
>Adding description for every unexpected 
>behaviour is like trying to prevent a breach in 
>a dyke by explaining to the water that it should 
>go somewhere else. If the language would behave 
>as expected, there would be less airquote & bug 
>& airquote reports immediately (and less 
>breaking dykes).
>
>Basically any confusion for a user should be an 
>opportunity to increase the reliability of the 
>user experience. Scrutinising  a user or putting 
>him down for being confused is a sure way to 
>have one user less.
>Therefore, Rev should make the labelVariable 
>changeable whenever any user wants, i'm pretty 
>sure that'd be not a  problem to do for them (as 
>it worked in earlier versions). Allowing changes 
>to the container variable is probably much 
>harder, but I'm sure something could be done 
>about that too.
>
>I also would like to add, that I often change 
>label variables in repeat for each loops, and 
>have had never any errors thrown because of it 
>(or unexpected results). I did however get 
>unexpected results from changing the container 
>variable.
>
>
>A voice for the mainstream user, not the specialist
>Björnke

-- 


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -