|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |