why ; ?

[Nick Sabalausky]

"Michael Neumann" <mneumann at ntecs.de> wrote in message 
news:fvvd1a$7p3$1 at digitalmars.com...
> terranium wrote:
> > Michael Neumann Wrote:
> >
> >> Another example which leads to hard to read code and potential
> >> bugs is (ignoring compiler warnings):
> >>
> >>      class A
> >>      {
> >>        int i;
> >>
> >>        //
> >>        // add some 25 lines of code here
> >>        //
> >>
> >>        void foo(int i)
> >>        {
> >>          // what is "i" here?
> >>        }
> >>      }
> >>
> >> This is solved in Ruby by using a separate namespace for instance
> >> variables ("@i" for instance variable "i", and "i" for local variable
> >> "i").
> >
> > In C family languages this is ruled out by naming convention.
>
> Which in the case of using a m_ prefix leads to hard(er) to read code.
> And then there is no standard naming convention, and who actually uses
> such a naming convention? Without that, you can't easily distinguish a
> local variable from an instance variable from a global variable.
>

In "good" C family languages, the instance variable is referred to by 
prefixing it with something like "this.". I think there are some that do it 
differently (ECMAScript, IIRC), but I'd argue those ones are making a big 
mistake.

However, that does bring up an inconsistancy inherent to the C-style. 
Following your example, if I do this:

class A{
int i;
void foo(int i) {}
void foo() {}
void bar() {}
}

In that case, "i" means one thing if you're in "foo(int)", and another thing 
if you're in "foo()" or "bar()". Of course, you could decide to *always* use 
"this." when referring to an instance variable, but that's kinda long, and 
you still end up with a hidden bug if you decide to use a local var named 
"i" and forget to declare it.

There are things about Ruby I don't like, but the @instanceVar syntax is one 
of the things I think it got spot-on. I would be totally in favor of 
adopting that.