Re: Symbol Name Length (Was: STL Memory leak?)
On Apr 8, 5:41 pm, Daniel Pitts
<newsgroup.spamfil...@virtualinfinity.net> wrote:
James Kanze wrote:
On Apr 7, 7:34 pm, Daniel Pitts
<newsgroup.spamfil...@virtualinfinity.net> wrote:
blargg wrote:
[...]
And of course, I notice that you've adopted a convention for
abbreviating names as well: why not sourceString and
destinationString? (Objects should be qualified nouns, and
abbreviations aren't used, according to the usual naming
rules.)
Why should they be qualified? Are your referred to as
PersonJames or JamesPerson? or, pJames to adopt some M$
notation...
It's just an old rule I thought I'd throw out: names of types
are unqualified nouns, names of variables are qualified nouns,
and names of functions are verbs (or verbal phrases). As a
general rule for coding, it's not bad, and it does avoid the
need for a lot of special rules. Thus, for example a "setter"
for state will assign "newState" to "currentState", and you no
longer have the problem of function parameter name and member
name conflicting.
(As for your example, there's a very real sense that a propre
name works as a "qualified noun". James specifies a specific
person, and not just any person. And if there were two James,
one a person, and one a dog, you might say James the person, as
opposed to James the dog.)
In the context I cited it, however, I was being somewhat
facetious. It's a good general rule, but almost by definition,
general rules don't apply to all specific cases. (Otherwise,
it's an absolute rule.) In practice, I do use the identifiers
source and dest when the name of the function makes it clear
what "source" and "dest" refer to; for that matter, I'll even
use them in cases where the type (e.g. std::istream&) makes it
evident. And I use "dest", and not "destination", even though
it is an abbreviation, and the general rule also says no
abbreviations. (It is, in fact, almost the only abbreviation I
use. The only other one which comes to mind is ptr, for
pointer.)
As an absolute rule (which requires compelling justification to
violate), you should be consistent. If you do use "dest" in one
place, rather than "destination", then you should use it
everywhere---there should be no "destination" (nor "dst") in the
code.
My point with that is you should choose the simplest name that
conveys enough information. The difficulty, as always, is
that both "simplest" and "enough information" are subjective
terms. Hopefully the "average" person will have an "average"
interpretation of simplest-with-enough-information.
Agreed. My point was just that this difficulty exists; that the
rule can be ambiguous. To which I would add that consistency in
naming is important---so the name chosen must convey enough
information in all contexts that it might appear. (If I see *d
on the left side of an assignment, the context tells me that it
is a destination. But there are obviously a lot of contexts
where "d" would not convey this information, so just "d" is not
enough information.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34