Warp wrote:
>   Something is "visual noise" when it makes the code *harder* to read
> because the "noise" is interfering with your capability of easily
> understanding the code.

Yep, you got it.  I have to mentally edit out the qualifiers as I'm reading 
the code to understand what it's trying to do.

>> I far, far prefer taking the 10 seconds at the start to come up with an 
>> unambiguous name that is clear how global the variable is.
> 
>   A common naming convention makes it much easier and unambiguous. Readers
> don't have to start guessing if it's really a global variable or not.

I don't have to guess. I read the code.

> (they may even be in a completely different file).

You're probably doing it wrong if they're in a different file. Or you're 
using a language that unnecessarily makes it necessary.

>   And since member variables are never in the public or protected parts of
> classes, there can be no ambiguous usage in a derived class member function.

I'm confused. You're telling me a subclass shouldn't refer to a superclass's 
members? Why is there even the concept of "protected" if a subclass 
shouldn't refer to a superclass?

>   (Yes, I know some people put them in the public part of their classes,
> and then write derived classes which refer to them directly without any
> qualifications. But these are the same people who would use hungarian
> notation in the wrong way, etc. Bad code is always bad code.)

When you're using properties, that's what you're *supposed* to do. That's 
what they're for.

> 
>> I have
> 
>> GameComponent -> DrawableGameComponent -> Boll -> StackableBoll -> 
>> StackableScreen -> UIScreen -> MenuScreen -> OptionScreen -> PlayOptionScreen.
> 
>> Where in that chain would something as poorly named as "mCounter" be found? :-)
> 
>   Which class' member function are you reading? If it's an unqualified use,
> it's a member of that class. (If it isn't, then you have breached good OOP
> guidelines.)

Nonsense. The menu title is as much a member of the Options screen as it is 
a member of a StandardMenuScreen as it is a member of a MenuScreen.  How are 
you supposed to set it if there's no accessibility from outside the class? 
How does the Options screen set the MenuScreen's title if the Options screen 
can't access any members?

>>> the first two are much clearer than the third one. The third one doesn't
>>> make it clear at all where 'counter' might be defined, while in the first
>>> example it's clear that it's a member variable of the Foo class,
> 
>> Is it? Or is it a member variable of a base class of the Foo class?
> 
>   If it's a member variable of the base class, then the OO design is crappy.
> No member variables in the public (or protected) interface.

What makes you think it's a variable?  I use properties for all that sort of 
stuff.  And why are variables in the public or protected interface bad design?

Don't confuse "C++ is easier when I do this" with "Good OOP design in general."

>   "I just use an IDE to tell me" is not a solution. It's an acknowledgement
> that there is a problem.

I disagree. It's an acknowledgment that automated maintenance of that 
information is more effective than manually maintaining it. It's no more a 
problem to use the IDE to do that than it is to declare something "const" in 
C++ instead of how you would handle it in C. It's using the tools we have to 
reduce the burden on the programmer.

I'm generally against redundancy in programs. Adding things to the code that 
the compiler can already provide for me is something that I find has always 
been problematic.

If I had no IDE, no syntax coloring, and I was using a language where 
figuring out what file something is declared in is a difficult and 
time-consuming problem, I'd probably suck it up and start labeling variable 
names with information about where I declared them. (Except, of course, in 
my work job, they can't even get the type declarations consistent, let alone 
something as unenforced as "m" and "g" flags. I'm lucky if I can guess which 
processor the code runs on.)

-- 
Darren New, San Diego CA, USA (PST)
    Eiffel - The language that lets you specify exactly
    that the code does what you think it does, even if
    it doesn't do what you wanted.

Post a reply to this message