Re: Should the 'this' pointer be explicitly used as a rule?
On Oct 31, 7:54 pm, Pavel
<pauldontspamt...@removeyourself.dontspam.yahoo> wrote:
James Kanze wrote:
Of course, with really good naming, you don't need anything;
the name contains enough semantic information so that it's
obvious whether it is a member (from the semantics). In
practice, I've found that most people (including myself)
don't name that well, and that the my_ prefix (or our_ for
static members) is helpful in many cases, enough to be worth
standardizing on. (But I admit exceptions: public data
members, for example, don't normally get it.)
[...]
The best would have been if there were some way
of enforcing good enough names so that the distinction
wouldn't be necessary. In practice, I find too that the
real motivation for the prefix/suffix is laziness: I'm too
lazy to create significantly different names for parameters
and members in the setters. (The real convention should
probably be to "prefix" both: my_state or my_current_state
for the member, and new_state for the parameter, or
initial_state if it is a parameter of a constructor. But as
I said, I'm too lazy to do this consistently.)
BTW, there used to be a convention to use an 'a' article for
parameters: void draw(Shape aShape){...}. That was not too bad
except that sometimes it read ugly for native English speakers
(e.g. string join(const vector<string> &aParts) or
copy(Iterator aBegin, Iterator anEnd, Iterator aDestination)).
I've seen that one, too. For plurials, they used some, e.g.:
someParts (instead of aParts).
Some drawbacks of encoding scope and accessibility into "good
names" (I assume you mean the names encoded as self-explaining
short phrases):
1. Laziness is the fact of life (and the driving engine of the
progress at that); if even you with your rigor admit being
lazy, how can you reasonably expect from others not to?
Realistically, I don't expect it, but the projects I've worked
on where the programmers have come closest to the ideal are also
those which ended up the most robust (and were the least
expensive to develop in the long run).
2. The accessibility and scope of a name are "always there"
whereas semantics changes and may on an occasion clash with
whatever "wordy" naming convention you choose.
This is a serious problem. If the semantics of a parameter
changes, you have to examine every call site, to be sure that
the arguments passed correspond to the new semantics.
Realistically, this means that you must change the name of the
function, or possibly the types in a way that won't compile, so
that you get a compiler error. If you're providing lower level
functions for other users, you may even have to continue to
provide the old function, with the old semantics, along side the
new one.
--
James Kanze