Nicolas Alvarez wrote:
> Darren New wrote:
>> Warp wrote:
>>>   Why object about wrong usage of hungarian notation in particular?
>> Because, as I said in the first post, the easiest way to maintain the
>> hungarian notation correctly is to use an IDE sophisticated enough you
>> don't need hungarian notation to start with.
> 
> My IDE uses different colors for global variables and member variables.
> No need for m_ or g_ if the colors say enough :)

Yep. That's what I'm saying. By the time your IDE is smart enough that 
changing the scope of a variable isn't a tedious process of hunting down all 
the references and changing the name, it's probably already recoloring 
things so you can tell without the prefix.  All the prefix is doing is 
putting into ASCII the stuff the compiler already knows, and making you 
manage it by hand. (Which is true of an awful lot of C coding, come to think 
of it. :-)

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

Darren New <dne### [at] sanrrcom> wrote:
> For the same reason. When you move it from being a member variable to a 
> function argument, or from a private member variable to a protected member 
> variable or a public member variable, you have to go and find and rename 
> them. And most of the time, it's visual noise.

  I have never understood this obsession some people have with "visual
noise". It seems that anything that exist to make a name more unambiguous
is always classified as "useless visual noise".

  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.

  Something which in some situations might not convey any additional
information to you is not "visual noise". You might use the word "redundant"
in the sense that it conveys the same information in more than one way (at
least in the context in question), but that's completely different from
"noise", which is something that is disruptive and makes it more difficult
to get the actual information.

  For example, you might have something like this:

    int Point::getX() { return x; }

  If you follow a naming pattern like being discussed here, it might instead
look like:

    int Point::getX() { return mX; }

  That's not "visual noise". It's not any harder to read and understand. You
might call it "redundant" (at least in this specific context, as the function
is so short and straightforward), and that's fine, but it's not "noise".

  You could even have it like this:

    int Point::getX() { return this->mX; }

  Now it's doubly-redundant because the same information (ie. that 'mX' is
a member variable of Point) is basically told three times, but it's still
not "visual noise". It's still pretty clear, readable and easy to understand.

  Where the 'm' prefixes start helping is when you have much more complicated
member functions which refer to local variables, function parameters, global
variables and member variables, especially when the names of the variables
are much less obvious.

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

> Maybe prefixing something with "g" to mean global (altho "s" to be static 
> might be better?;-) makes some sense, if your program has maybe two or three 
> actual globals. But for member variables vs arguments vs locals? No, that's 
> all right in front of you.

  There may be dozens of member variables, and the place where the member
variables are declared may be far away from the place where they are used
(they may even be in a completely different file). Seeing right away when
a variable is a member helps understanding such code.

> And "mCounter" is a member variable of... what class?

  If it's written as-is, without any reference or qualification, it's rather
obviously a member of 'this' (or whatever your language might call it). If
it has a reference or qualification, then it's obviously a member of that
class. One ought to know which class' member function one is reading and
trying to understand.

  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.

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

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

> For that matter, where in that chain would you find the static/global 
> "NextDrawAction"?

  Same thing as with member variables.

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

> Why would I do that, when I can hover the mouse over the name and have it 
> come up and say "int Bar::Counter instance variable"?

  You don't realize that you are actually acknowleding the problem: You
acknowledge that if the name of the variable is so ambiguous, you need a
specialized program to tell you where it might be defined because otherwise
it's very difficult to know. Hence the name is ambiguous, and it's not
possible to easily know what it's referring to unless you do some research
or use some program to find the declaration.

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

-- 
                                                          - Warp

Post a reply to this message

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

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

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

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

I find this (to steal the example from the other group):

std::vector< std::string > v1 = someFunction();
std::vector< std::string > v2;
std::transform( v1.begin(), v1.end, v2.begin(), std::bind1st( 
std::not_equal_to<
std::string >( "" ) ) );
for( std::vector< std::string >::iterator i = v2.begin(); i != v2.end(); 
++i )
    std::cout << *i << std::endl;

much harder to read than this:

vector< string > v1 = someFunction();
vector< string > v2;
transform( v1.begin(), v1.end, v2.begin(), bind1st( not_equal_to<string >( 
"" ) ) );
for( vector< string >::iterator i = v2.begin(); i != v2.end(); ++i )
   cout << *i << endl;

And IMO I definitely count all those repeated "std::" as noise in the code 
that does very little to enhance my understanding but severely slows down 
the speed I can read and type it.

Sure if you want very formal code with no chance of ambiguity the 1st is 
better, but the longer lines and extra typing put me off.

Post a reply to this message

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

  You magically know from the name of the variable that someone changed its
scope?

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

  As I said, you are just acknowleding that there *is* a problem in the
naming which has to be solved by using an IDE.

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

  This whole thread has been about variables. Nobody has talked about
functions.

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

  Because from the point of view of the derived class the member variable
is public, and thus with all the drawbacks.

> And what about member properties?

  Getter and setter functions are a separate issue. We are not talking
about member functions here. (Or at least I am not.)

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

  If you want to use confusing syntax, that's up to you. ("Not only do not
I know if this is a local, global or member variable, I don't even know if
this is actually a property of this class or any of its base classes." Way
to add even more confusion.)

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

  Since classes don't have public member variables, it is a function (even
if the syntax is confusing). Haven't you learned already?

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

  Getters and setters are member functions, not member variables, and hence
other naming conventions apply to them.

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

  You use getter and setter functions, which are named with the proper naming
convention for member functions.

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

  Well, if you deliberately want to make it ambiguous and confusing, that's
up to you. But remember that others may need to read and understand your
code. That "Title" doesn't make it at all obvious what it might be and
where it might be declared.

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

  Abstraction. A member variable is part of the internal implementation of
the class, while a public member function is part of its abstract public
interface which should usually reveal as little as possible about the
internal implementation details of the class.

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

  I'd call it confusing.

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

  Then maybe you should learn more about object-oriented programming
principles, then?

  If you expose a member variable, you are exposing an internal
implementation detail and thus making your class less abstract, making
it harder to modify later. Internal implementation details should be
hidden as well as possible so that changing these details becomes easier
without breaking the rest of the program.

  It's not a compiler-technical issue. It's an issue of program design.
It has nothing to do with a specific programming language.

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

  Well, usually you shouldn't have global variables in a well-designed
program. As for not having free functions, I don't quite get it. What's
wrong with having some convenience functions?

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

  That's the problem: You have to "look it up". The name itself tells you
nothing. You have to study the rest of the code in order to understand what
the function is doing, and the name of the variable is giving you no hints
on where you might start looking.

  However, if you see from the name that it's eg. a member variable, then
there aren't many places you have to look for it.

  This becomes especially useful when there are dozens of different variables
being referred to in a function.

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

  Seemingly you are, given how much you advocate using an IDE to look up
variable definitions.

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

> You're begging the question.

  I'm not. You are against redundancy. Are you also against redundancy when
it makes the code more readable?

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

  Haha.

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

  If it isn't, then your program is badly designed and hard to understand.

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

  You are making contradictory statements. In one place you say that you
don't need any special naming conventions because you just use the IDE to
tell you where variables are defined, and here you are telling that you are
actually *not* using 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.

  The type of the variable doesn't help you find its declaration. A naming
convention telling you where to look does.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> 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.

> I find this (to steal the example from the other group):

> std::vector< std::string > v1 = someFunction();
> std::vector< std::string > v2;
> std::transform( v1.begin(), v1.end, v2.begin(), std::bind1st( 
> std::not_equal_to<
> std::string >( "" ) ) );
> for( std::vector< std::string >::iterator i = v2.begin(); i != v2.end(); 
> ++i )
>     std::cout << *i << std::endl;

> much harder to read than this:

  Of course it doesn't help that the indentation sucks.

> vector< string > v1 = someFunction();
> vector< string > v2;
> transform( v1.begin(), v1.end, v2.begin(), bind1st( not_equal_to<string >( 
> "" ) ) );
> for( vector< string >::iterator i = v2.begin(); i != v2.end(); ++i )
>    cout << *i << endl;

  Well, I find the first example easier to read (after proper indentation)
because I see much faster with a quick scan which names are from the
standard C++ library and which are local variables or reserved keywords.

> And IMO I definitely count all those repeated "std::" as noise in the code 
> that does very little to enhance my understanding but severely slows down 
> the speed I can read and type it.

  You might as well argue that all the ';' symbols are "noise in the code"
which add nothing and make it more difficult to read and write (after all,
the example would be completely unambiguous and parseable without them).

  Of course to others the ';' symbols actually make the code easier to
read because they are a visual clue to quickly see where a statement ends
and the next begins.

> Sure if you want very formal code with no chance of ambiguity the 1st is 
> better, but the longer lines and extra typing put me off.

  I have never, and will never understand some people's infatuation with
brevity.

  In programming brevity is not a virtue. If you want brevity, check the
IOCCC.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>>> 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. :-)
> 
>   You magically know from the name of the variable that someone changed its
> scope?

No. I'm saying if you name the variable "gCounter" everywhere, and then 
decide you really need to be able to have more than one instance, then you 
better rename it to mCounter everywhere you use it, or you've made it even 
*harder* to understand than if you hadn't flagged it at all.

Basically, your prefixes are comments, and wrong comments can be worse than 
no comments.

Now, I already granted that such doesn't happen very often, but that's the 
point I'm making here.  Let it go long enough with sufficiently careless 
programmers, and you'll have this problem. Using an IDE will prevent that 
problem.

>   As I said, you are just acknowleding that there *is* a problem in the
> naming which has to be solved by using an IDE.

No. I'm acknowledging that if your class is so complex that you can't easily 
figure out where the variable is declared, chances are good that a naming 
convention isn't going to help all that much.

Or, to put it another way, I've tried it. It didn't do anything for me.  It 
didn't help my understanding, even when reading code written by the guy who 
did things that way.  That doesn't mean it's right or wrong. It just means 
that asserting it's always appropriate is probably incorrect.  If I can't 
figure out that a variable is a member variable from its name without the 
flag, chances are I'm picking a crappy name for that member variable. 
Something like "mCounter" for example.

For example, "CounterOfInstancesCreated" is obviously going to most likely 
be a class-level static variable. "CounterOfMenuEntries" is probably an 
instance variable in the class "Menu". It probably sizes the array 
"MenuEntries" in the class Menu. "CounterOfEntriesUpdatedSoFar" is probably 
a local variable. "CounterOfEntriesToRemove" is probably a function argument.

>>>   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.
> 
>   This whole thread has been about variables. Nobody has talked about
> functions.

Well, *I* was. I can't help you started putting arbitrary limitations on how 
you use your language without telling me. :-)

Now, if you wanted to argue that you put "m" in front of private local 
variables to distinguish them from properties, you might have a point there. 
But then that defeats the purpose of using properties.

>>>   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?
> 
>   Because from the point of view of the derived class the member variable
> is public, and thus with all the drawbacks.

You haven't told me what the drawbacks are. I suspect the drawbacks are 
specific to languages where function calls don't look like variable 
accesses. If your getters and setters look like variable assignments, why 
would it be problematic to have actual variables in the public interface?

>> And what about member properties?
> 
>   Getter and setter functions are a separate issue. We are not talking
> about member functions here. (Or at least I am not.)

OK. Since pretty much all my non-private variables are accessed via 
getter/setter functions (i.e., properties), then I don't see a problem here.

>> It doesn't. But the syntax is that of a variable.
> 
>   If you want to use confusing syntax, that's up to you. ("Not only do not
> I know if this is a local, global or member variable, I don't even know if
> this is actually a property of this class or any of its base classes." Way
> to add even more confusion.)

Well, (A) it's part of the language, so it's not really confusing syntax, 
and (B) it's hiding whether it's a variable or a function for exactly the 
same reason you're making private variables private.


>> I.e.,
>>     x.a = 27;
>> does not tell you whether "a" is a variable or a function in C#.
> 
>   Since classes don't have public member variables, it is a function (even
> if the syntax is confusing). Haven't you learned already?

Um, sorry. "Warp's C++ programming style" doesn't define C# syntax, I fear.

>   Getters and setters are member functions, not member variables, and hence
> other naming conventions apply to them.

OK.

>> 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?
> 
>   You use getter and setter functions, which are named with the proper naming
> convention for member functions.

Huh. And the proper naming convention for that in C# is to make it look like 
a member variable. Funny that.

> 
>>>   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";
> 
>   Well, if you deliberately want to make it ambiguous and confusing, that's
> up to you. But remember that others may need to read and understand your
> code. That "Title" doesn't make it at all obvious what it might be and
> where it might be declared.

There's nothing in front of it (like this. or something) so it's a property 
or variable declared in this class or a superclass thereof. It's really not 
confusing or ambiguous.

>   Abstraction. A member variable is part of the internal implementation of
> the class, while a public member function is part of its abstract public
> interface which should usually reveal as little as possible about the
> internal implementation details of the class.

Well, there ya go then. If I declare a property, then it's a function that 
syntactically looks like a variable. It reveals very little about the 
implementation, in that there need not be a backing variable at all.

Plus, if I make it a variable, technically I can replace *that* with a 
function call in the future, with a simple recompile of the users of that 
code, because the syntax is the same.

A property says "if you can set this and get this, then what gets returned 
from the 'get' is almost certainly what you assigned with the 'set'."

It's only confusing if you don't know the language, and no more confusing 
than having to find which implementation of a virtual function a given call 
site invokes.

>> 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?
> 
>   I'd call it confusing.

That's because you're not used to it. It's basically a way of defining a 
getter/setter pair that makes it clear it's a getter/setter to the caller.

>   If you expose a member variable, you are exposing an internal
> implementation detail 

No I'm not. Part of the API for a menu screen is the title of the menu and 
the color it's drawn in. That's not an implementation detail.

>   It's not a compiler-technical issue. It's an issue of program design.
> It has nothing to do with a specific programming language.

But you said right there it is, you see. If the syntax for assigning to or 
from a variable is the same as the syntax for calling a getter or setter, 
then you can trivially change from using a variable to using functions in 
the future.

It would be like me arguing that C++ functors should have a different syntax 
than functions for invocation, because otherwise it's confusing. No, that's 
the *point* - if the user has to know whether it's a property or a variable, 
*then* your design is bad.

>> 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.
> 
>   Well, usually you shouldn't have global variables in a well-designed
> program. As for not having free functions, I don't quite get it. What's
> wrong with having some convenience functions?

I didn't say there's something wrong. I said it's not OOD.

>> 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.
> 
>   That's the problem: You have to "look it up". The name itself tells you
> nothing.

I have to look up whether it's an int or a float, too. I don't encode that 
into the variable name either. Certainly if you're arguing that "mCounter" 
is good style, then surely "m_pszTitle" is good style.

> You have to study the rest of the code in order to understand what
> the function is doing, 

I would argue that *this* is the problem. :-)

It's also a problem that properties eliminate for getter/setter code: You 
know from the fact it's a property what it's doing. Indeed, the whole reason 
C# has properties is to eliminate the whole problem of "this used to be a 
variable and now I have to do something to calculate it instead" or vice versa.

 > and the name of the variable is giving you no hints
> on where you might start looking.
> 
>   However, if you see from the name that it's eg. a member variable, then
> there aren't many places you have to look for it.

There's already not a lot of places I have to look for it. If I stick with 
only having variables be private, I have to look in the function arguments, 
the local declarations, and the member variables of the class I'm in. The 
function arguments and local declarations are right next to the code using 
the variable.

>   This becomes especially useful when there are dozens of different variables
> being referred to in a function.

I'd also argue that's a problem with your design, unless you're actually 
doing something sufficiently complicated that you're going to have to look 
up the types of the variables too. If I'm manipulating dozens of member 
variables in a function, it's likely either a list of relatively independent 
statements (like initializing dozens of parameters to their defaults) or a 
function I should be refactoring.

>>>   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.
> 
>   Seemingly you are, given how much you advocate using an IDE to look up
> variable definitions.

So when you see mCounter in your code, how do you know what type it is?

I don't rely on the IDE to look things up. But since it's there, I use it.

> 
>>>> I'm generally against redundancy in programs.
>>>   Are you against readability?
> 
>> You're begging the question.
> 
>   I'm not. You are against redundancy. Are you also against redundancy when
> it makes the code more readable?

No, but you're assuming that your form of redundancy makes the code more 
readable simply by asking the question. (I can't see any reason why you 
would ask such a question except to imply that the redundancy you advocate 
makes code more readable, which is exactly what we're discussing. However, I 
may be misreading why you asked such a question. But I think not, given that 
no reasonable programmer would be against readability, making it either a 
rhetorical question or an insult.)

>> 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.
> 
>   Haha.
> 
>> Especially if you're going to assert that "mCounter" is always a member 
>> variable of *this* class.
> 
>   If it isn't, then your program is badly designed and hard to understand.

Well, we're talking about somewhat different things here, then.

> 
>>>   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.
> 
>   You are making contradictory statements. In one place you say that you
> don't need any special naming conventions because you just use the IDE to
> tell you where variables are defined, and here you are telling that you are
> actually *not* using the IDE for readability.

I don't *need* the IDE to look up variables, and I don't *rely* on the IDE 
for readability. Of course, ASCII code without an IDE is less readable than 
with an IDE. That doesn't mean *your* solution to not using an IDE is the 
best one, or even necessary.

>   The type of the variable doesn't help you find its declaration. A naming
> convention telling you where to look does.

But if all member variables are private, I don't need a naming convention to 
tell me where to look. If it's not a function argument or a local variable, 
it's a member variable.

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

Darren New <dne### [at] sanrrcom> wrote:
> >   As I said, you are just acknowleding that there *is* a problem in the
> > naming which has to be solved by using an IDE.

> No. I'm acknowledging that if your class is so complex that you can't easily 
> figure out where the variable is declared, chances are good that a naming 
> convention isn't going to help all that much.

  On the contrary. The more complex the class is, the more helpful naming
conventions are. It's the exact opposite of what you are saying.

  Naming conventions of variables are not so much necessary with very small
and simple classes, as there is less code to read and understand, and
functions tend to be much shorter. OTOH, if you have used a certain naming
convention in your more complex classes, it's a good idea to use the
convention everywhere for consistency and to avoid confusion ("why is
this naming convention used here but not there?")

> For example, "CounterOfInstancesCreated" is obviously going to most likely 
> be a class-level static variable. "CounterOfMenuEntries" is probably an 
> instance variable in the class "Menu". It probably sizes the array 
> "MenuEntries" in the class Menu. "CounterOfEntriesUpdatedSoFar" is probably 
> a local variable. "CounterOfEntriesToRemove" is probably a function argument.

  Citing a few very specific examples where it's easier to *guess* where
something is defined doesn't mean that it's *always* so easy to make that
guess, no matter how well you try to name your variables.

  The best situation is when you don't have to guess at all.

> >>>   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?
> > 
> >   Because from the point of view of the derived class the member variable
> > is public, and thus with all the drawbacks.

> You haven't told me what the drawbacks are.

  Because it's an extensive subject. I have told you how to get more
information on that subject: Get a good book.

  It's related to modularity and abstraction.

> I suspect the drawbacks are 
> specific to languages where function calls don't look like variable 
> accesses. If your getters and setters look like variable assignments, why 
> would it be problematic to have actual variables in the public interface?

  Many object-oriented developers frown upon abusing getters and setters
(even if the language helps you creating them automatically) because they
are only slightly better than direct public member variables.

  It's a problem of design: If you have too many getters/setters in the
public interface, you are exposing too much of the internal implementations
of the class, and hence your class' public interface is not abstract enough.

  Just because the programming language might make it easier to create such
getter/setter pairs doesn't mean it's a good idea to abuse the feature.

> >> It doesn't. But the syntax is that of a variable.
> > 
> >   If you want to use confusing syntax, that's up to you. ("Not only do not
> > I know if this is a local, global or member variable, I don't even know if
> > this is actually a property of this class or any of its base classes." Way
> > to add even more confusion.)

> Well, (A) it's part of the language, so it's not really confusing syntax, 

  It being part of the language doesn't make it any less confusing. It's
confusing if it's hard to tell from a name where it might be defined. If
it looks like a variable but isn't, then it can be even *more* confusing.

  The property syntax may be a handy convenience shortcut, but just because
it exists doesn't mean it cannot be abused and obfuscated code cannot be
created with it.

> and (B) it's hiding whether it's a variable or a function for exactly the 
> same reason you're making private variables private.

  But does it help readability? Less typing doesn't always equate with
better readability.

> >> I.e.,
> >>     x.a = 27;
> >> does not tell you whether "a" is a variable or a function in C#.
> > 
> >   Since classes don't have public member variables, it is a function (even
> > if the syntax is confusing). Haven't you learned already?

> Um, sorry. "Warp's C++ programming style" doesn't define C# syntax, I fear.

  You didn't understand what I was saying.

  You *don't* have public member variables, period. Hence if you are doing
"x.a" from the outside, that 'a' is *not* a public member variable, period.
Hence the only thing it can be is a public member function.

  You have some kind of obsession that I'm always talking about C++. Forget
about C++. I'm talking about object-oriented programming.

> >> 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?
> > 
> >   You use getter and setter functions, which are named with the proper naming
> > convention for member functions.

> Huh. And the proper naming convention for that in C# is to make it look like 
> a member variable. Funny that.

  Are you telling me it's *impossible* to make getter/setter functions in C#
which actually look like functions? They have gone the extra mile to actually
forbid that?

  As I said, if you really want to make your code more confusing, it's your
prerogative.

> >>>   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";
> > 
> >   Well, if you deliberately want to make it ambiguous and confusing, that's
> > up to you. But remember that others may need to read and understand your
> > code. That "Title" doesn't make it at all obvious what it might be and
> > where it might be declared.

> There's nothing in front of it (like this. or something) so it's a property 
> or variable declared in this class or a superclass thereof. It's really not 
> confusing or ambiguous.

  It could be a local variable. Or a function parameter. Or variable in the
file scope. Or a global variable.

> >   Abstraction. A member variable is part of the internal implementation of
> > the class, while a public member function is part of its abstract public
> > interface which should usually reveal as little as possible about the
> > internal implementation details of the class.

> Well, there ya go then. If I declare a property, then it's a function that 
> syntactically looks like a variable. It reveals very little about the 
> implementation, in that there need not be a backing variable at all.

  But makes it unclear where it might have been declared if you call it
without qualifications.

> It's only confusing if you don't know the language

  I have never talked about any C# property syntax being confusing, even
tough you seem to think I have. I have been talking about variable naming
being confusing, and how deliberately abusing properties can make them
even *more* confusing than they already were.

> and no more confusing 
> than having to find which implementation of a virtual function a given call 
> site invokes.

  "Having to find out which function is being really called in this
inheritance hierarchy can sometimes be confusing, hence it doesn't matter
if finding out variable declarations is equally confusing" is not really a
good argument.

> >> 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?
> > 
> >   I'd call it confusing.

> That's because you're not used to it. It's basically a way of defining a 
> getter/setter pair that makes it clear it's a getter/setter to the caller.

  You still can't get your head around the fact that I'm not talking about
the syntax, but about variable naming conventions.

> >> 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.
> > 
> >   Well, usually you shouldn't have global variables in a well-designed
> > program. As for not having free functions, I don't quite get it. What's
> > wrong with having some convenience functions?

> I didn't say there's something wrong. I said it's not OOD.

  Exactly which part of OOD forbids free functions, and most importantly, why?

> >> 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.
> > 
> >   That's the problem: You have to "look it up". The name itself tells you
> > nothing.

> I have to look up whether it's an int or a float, too.

  And the naming can help you finding out where to look, making that task
easier. So?

> I don't encode that 
> into the variable name either. Certainly if you're arguing that "mCounter" 
> is good style, then surely "m_pszTitle" is good style.

  Is it "all or nothing" to you? Either you have to put *everything* related
to the variable in its name, or you shouldn't put anything at all?

  That would be a false dichotomy.

> > You have to study the rest of the code in order to understand what
> > the function is doing, 

> I would argue that *this* is the problem. :-)

  You can't always avoid it. If a single character in the variable name makes
the task easier when you want to do it, so much the better.

  Besides, it's not always about just finding the declaration. It's more
often about simply understanding the code. When you see that a member
variable is being used you don't necessarily have to look at its declaration;
it may still be easier to understand than if the name didn't make it clear
if what is being used is a member variable or something else. When many
variables from different sources are being heavily used in a short piece
of code, it helps understanding what is being done to what when you
directly see what is a member variable and what is something else.

-- 
                                                          - Warp

Post a reply to this message