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