Warp wrote:
>   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.)

OK. I find it's like having misspellings and bad punctuation in prose. It 
makes me stumble and have to figure out whether it's part of the name or not.

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

Even after someone has gone and changed it from a global to a member 
variable without updating all the names, yes. :-)

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

Yep. But with a decent language and/or IDE, it doesn't really matter how far 
away the member variables are, or what file or superclass they're in. I 
don't feel the need to have a naming convention help me harness the full 
power of the language if the compiler already does that.

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

I fail to see how a superclass with all members private can be useful. 
Unless you're using "member" to mean "instance variable" rather than 
"instance function" or something.

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

Why?

And what about member properties?

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

It doesn't. But the syntax is that of a variable. Plus, C# has "anonymous 
properties", which are properties where the compiler generates a name for 
the variable acting as the store of the value, in case you want to have 
properties for the future but they really could be variables now.

I.e.,
    x.a = 27;
does not tell you whether "a" is a variable or a function in C#.

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

What if you use variable syntax for getters and setters, just like C++ lets 
you use array subscripting syntax for function calls?

If I have a string that's the title of the menu in a base class, and it's a 
property that uses variable syntax, what should I name it and how would I 
refer to it in the subclass?

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

I *am* calling a member function to set it up. The member function is 
invoked by me saying
    Title = "Game Options";

What should I name that?

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

I don't even know from *inside* the class that declares it what the member 
variable is called.

>>> 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 what exactly is the difference, theoretically speaking? Syntax? 
Implementation? Future-proofing the code?

Is a getter/setter pair syntactically invoked like a variable and whose 
underlying storage is inaccessible even to the class declaring the 
setter/getter a member variable or a member function?

>> And why are variables in the public or protected interface bad design?
> 
>   Buy some good book about object-oriented programming sometime.

So you don't know either?

>> 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 know nothing in OOP that says exposing member variables that act like 
variables is a bad idea. I know it's a bad idea in C++ and a few other 
languages, and I know that some other languages (like Eiffel and C#) make it 
not a bad idea. The worst that happens is if you change your mind you have 
to recompile the code that uses it.

Indeed, having functions unassociated with classes and having global 
variables at all is a much worse OOP design than having variables exposed in 
the class interface.

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

But I don't. I can look up whether it's a global or not just fine without an 
IDE. I don't feel the need to encode that into the names, is all.

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

I agree. However, I'm not depending on the IDE to make the code readable.

>> I'm generally against redundancy in programs.
> 
>   Are you against readability?

You're begging the question.

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

Having to resort to a naming convention to tell the reader what you already 
told the reader is a tell-tale sign that the program could have been written 
better too.

Especially if you're going to assert that "mCounter" is always a member 
variable of *this* class.

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

I'm not relying on the IDE for readability. I'm having the IDE assist me in 
easily finding the declaration of the variables I'm using. Whether it's a 
member variable or a global variable is of much less interest than the type 
of the variable, and I don't encode that into the name either.

Since 99.5% of all my variables are either auto declared where used, 
function arguments on the same screen as the code I'm reading, or member 
variables, putting "m" before every variable that isn't declared on the same 
screen as I use it is visual noise to me. I have an entire video game with a 
total of one count-em one global variable, and the purpose of that variable 
is to pass information between methods invoked off a linked list of 
instances about what the previous instance (whichever got selected) wants 
the next instance to do.

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