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