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

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

I'm saying that if your class is too complicated, you should simplify it, 
not add comments everywhere you refer to a variable to remind you its purpose.

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

Agreed.

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

Agreed.

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

Also agreed. But I think using a prefix on a variable that's essentially a 
comment telling you where to look for the definition everywhere you read or 
write the name of a variable is not the best solution.

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

I've read a number of books on the subject. The best advice is to use a 
language where the distinction is not a problem. The problem of having 
publicly available variables is caused by the language, not by the model. If 
the API has a value that acts like a variable, there's really not a 
conceptual problem with modeling it by a variable.

>   It's related to modularity and abstraction.

No, it really isn't. The only reason to do this is if the syntax for getters 
and setters differs from the syntax for variables. In that case, you want to 
use the same syntax everywhere, to avoid changing the callers if you decide 
it has to change from being a variable to a setter function.

abc = Menu.GetTitle()
isn't really any more abstract than
abc = Menu.Title

Nor is
Menu.Title = "Hello World"
any less abstract than
Menu.SetTitle("Hello World")

Some things really are that simple.

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

I disagree. If you have a menu-drawing class, and you want to know the font 
for the title, the color of the title, the string for the title, the font 
and color for the entries when unselected, when selected, whether the 
entries are aligned or not, etc etc etc, then there's no good reason not to 
use something that looks like a public variable.

>   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's not abuse. It's what they're for.

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

But because setters and getters are part of the language, it *doesn't* look 
like a variable, any more than
   my_vector[3]
looks like an array reference in C++

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

Well, sure. And if you're writing code that clearly does something more than 
set or get, then you shouldn't use a property. We know that already.

E.g., when adding an entry to the menu, it would be bad style to use a 
setter where "assigning" to the setter adds the text to the end of the list 
or whatever. The point of a property is that to outside classes it behaves 
like a variable.

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

Yes. It helps readability, modularity, and abstraction.

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

Who doesn't have public member variables?

I understand what you're saying.  I said "in C#."  You seem to be ignoring 
that, somehow implying that your personal style (don't have public member 
variables) is somehow enforced by C#. I'm saying "the language supports this 
with this syntax."  You're somehow implying "No, it doesn't, because it's 
bad style to take advantage of it" or something?

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

You're talking about what *you* think is good style for OO programming, 
which varies with different languages implementing OO programming. I'm 
disagreeing that your style guidelines apply to OO languages with different 
syntax and semantics.

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

No. I'm saying that you're trying to impose your style on the definition of 
C# for some reason. I'm saying that if you know C#, there's no confusion 
about properties or variables.

If you want to follow a style guideline that says "all member variables are 
private", then
   xyz.abc = 27;
immediately tells you abc is a property setter, so there's no confusion.

If you don't want to follow the convention that all member variables are 
private, then you can take advantage of that ambiguity to make your code 
more clear just like an OO program takes advantage of dynamic dispatch to 
make the code more clear.

Actually, C# is pretty much the most readable and maintainable language in 
that whole category that I've found. The details of the syntax and the rules 
and restrictions make it 99.5% of the time trivial to see what's going on.


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

No such thing as "file scope" in C#, because it's OO. No such thing as 
"global variable" in C#, because it's OO.

(Note that .NET does support those things, including stuff like FORTRAN 
/DATA/ blocks as well, but C# doesn't do that per se.)

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

Only to the extent that it's OO and thus inherited. I.e.,
    xyz.abc = "Hello";
isn't any more unclear than
    xyz->setAbc("Hello");
is in C++.

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

I'm not sure what "abuse" of properties you're talking about. Nobody is 
talking about "abusing" properties. The title of a menu, or the color the 
selected entry is drawn in, is a property of the menu. That's why 
"properties" have that name.

You indeed seemed to be calling the ambiguity between assigning to a 
property setter and assigning to a public variable to be confusing. Maybe I 
misunderstood. If it's not confusing, then I'm not sure what the problem is.

See two paragraphs down, where you say "I'd call it confusing" while talking 
about C# property syntax.

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

The solution to one is the solution to the other. Why only half-solve the 
problem?

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

^^^^  What's this? ^^^^  :-)


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

I understand. I have my head around it. I'm talking about, however, 
functions that look syntactically like variables, and I'm asking you whether 
you think they should be named like variables or not. You seem to say "no", 
at which point my opinion is reinforced that I don't need a naming 
convention for local private variables.


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

What class are they a member of? What instance is the distinguished 
instance.  They're functions unassociated with objects.  In a *very* OO 
class-based language, such functions aren't even possible.

(Yes, you can have OO languages like CLOS and such where member methods 
aren't associated with classes per se. Neither of us are talking about that.)

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

It's not worth the effort of maintaining it, for me.

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

No. I'm trying to figure out what your goal is. Telling you where to look up 
the type information makes more sense than encoding it in the variable. But 
to me, knowing it's either essentially on the same screen I'm looking at or 
it's an instance variable of the class I'm referencing seems sufficient to 
me. I don't really get confused when I'm reading code between what's a local 
variable and what's a function argument, so I'm not sure why I'd be confused 
between either of those and a member variable.

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

I'll disagree. Sure, *if* it does, then it's helpful. In my experience, 
however, it doesn't.

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

But under your rules (no public member variables in superclasses), I'd still 
know it was an instance variable, because it's unqualified but not declared 
in the function I'm looking at.

Now, granted, the code at work has 14,000-line-long functions implementing 
an entire application in main(). But I'd argue that adding flags to variable 
names isn't the right cure to the problem of a function not fitting on a 
screen or two.

Basically, you're asserting it's helpful in your experience. I'm asserting 
that in my experience it isn't. Absent anything scientific or even reasoned 
beyond "it tells you to look for the declaration outside the function", it 
doesn't look like you'll convince me. :-)

-- 
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 wrote:
> No. I'm saying that you're trying to impose your style on the definition 
> of C# for some reason. I'm saying that if you know C#, there's no 
> confusion about properties or variables.

BTW, C# already has naming conventions that covers much of what you're 
talking about, established by MS and used throughout the libraries. They're 
also much more extensive than simply how you capitalize variables you can 
trivially look up with the IDE. It makes it possible for me to know exactly 
the arguments to xyz.OnChange, xyz.OnChanging, and xyz.OnChanged, knowing 
nothing more than the conjucation of the verb there, for example. I also 
know how to start in the background any process I want to run that way, how 
to get the result back, what the functions will be called, etc.

I find it much more helpful to be able to look at a function call and say 
"Oh, that launches a thread that runs X, and when it finishes it'll invoke 
my Y function with two arguments that are .....".

The style guides are dozens of pages long, letting you read code written to 
that guideline and actually know useful information about it rather than 
just where to look up useful information.

I'm not against naming conventions, and I do think they improve readability. 
I just don't agree that "mCounter" vs "gCounter" is an example of that.

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

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

Sure, I know that already, but not everyone else shares your view.

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

There are several differences with ";".  It's only one character long, 
usually only appears 0 or 1 times on a line, and *often* gives you useful 
information.  On the contrary, "std::" is 5 characters long, often appears 
many times on one line, and very *rarely* helps to actually disambiguate any 
code.

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

As I said before, it makes the code easier and faster *for me* to read, and 
saves *me* time.  I understand how you feel and how you prefer the extra 
verbosity, but it's pretty shortsighted to say you don't understand other 
views when it's been explained to you 100 times.

Post a reply to this message