Darren New <dne### [at] sanrrcom> wrote:
> 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.

  Then I don't understand it. To me the qualifiers make the code easier to
read, not harder. (And no, I'm not talking about hungarian notation here.)

> >> 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.

  Even a couple of years from now?

> > (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.

  At least you acknowledge that the member variable declarations may be
very far away from their usage, making it hard to connect the two while
casually browsing the code, because you didn't nitpick about that part.

> >   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?

  A subclass cannot refer to a superclass' members because it has no access
to them. They are private.

> Why is there even the concept of "protected" if a subclass 
> shouldn't refer to a superclass?

  You put member functions and abstract types there (for the derived class
to use).

  A member variable in the protected section is as bad as in the public one,
hence you don't put member variables in the protected section.

> >   (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.

  If the getter/setter of a member variable has the exact same name as the
member variable (which in itself is a braindead idea IMO), you can still
put a qualification in front of the call.

  Of course a getter/setter should not be named like the member variable
itself. Naming a member function mCounter is not a good idea because that
notation should be reserved for member variables, not member functions.

> >> 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?

  Odd question. By calling a member function to set it up, of course.

  You shouldn't even *know* from the outside that the class has such a member
variable. It's private info.

> >>> 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?

  Because we are talking about the naming convention of member variables.
Member functions are a different story.

> And why are variables in the public or protected interface bad design?

  Buy some good book about object-oriented programming sometime.

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

  I'm not confusing anything. I'm talking about good object-oriented
programming principles.

> >   "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.

  It is a problem when you need the IDE in order to understand the program.

  Code readability should not rely on IDEs. It's precisely that reliance
that produces unreadable code which is hard to understand.

> I'm generally against redundancy in programs.

  Are you against readability?

> Adding things to the code that 
> the compiler can already provide for me is something that I find has always 
> been problematic.

  Having to resort to a compiler or IDE in order to understand a program is
a tell-tale sign that the program could have been written better.

> 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.

  Take into account that maybe others will have to read your code, and they
might not have that fancy IDE at hand at the moment, yet they may have to
understand your code. Relying on IDEs for readability is a bad idea.

-- 
                                                          - Warp

Post a reply to this message