Re: Symbol Name Length (Was: STL Memory leak?)
On Apr 7, 7:34 pm, Daniel Pitts
<newsgroup.spamfil...@virtualinfinity.net> wrote:
blargg wrote:
By the way, your naming convention is very verbose, and thus
obscures things. The scope of a variable should play a part
in the length of its name; smaller scope, shorter name. But
this is just a style issue.
Not to start a flame war, but I disagree. Names should
*always* reflect the semantics of what they represent as
concisely as possible. Take away all you can, but no more.
There's no arguing with that, but the original poster had a lot
of misinformation in his names. CScreen, rather than Screen
(which I would generally interpret as indicating that the class
was part of MFC) and the m_ prefixes on the local variables
(which is a common convention for member variables).
For example:
if (useNode) {
Node n; // n is to short, even for this short scope.
n.doStuff();
}
Yes, you can see n and very quickly look up to see it is a
Node, but you save a couple of brain-cycles if you use the
following.
if (useNode) {
Node node;
node.doStuff();
}
I'd probably write it like you just did, but as long as the
scope is only two or three lines, I could live (just barely)
with the first.
On the other hand,
for ( int i = 0 ; i < count ; ++ i ) {
a[ i ] *= 2 ;
}
is actually clearer than:
for ( int indexIntoArray = 0 ; indexIntoArray < count ; ++
indexIntoArray ) {
a[ indexIntoArray ] *= 2 ;
}
There are some universal conventions, including that of using i,
j, k for local indexes, which should be respected.
It doesn't obscure anything. Of course, these things are
always value judgments, and there is often reason to stray.
For example, I've seen the following two functions, which one
is easier to understand:
char *strcpy(char*a, char*b)
{
char *c = a;
while ((*b = *a) != 0)
{
++b;
++a;
}
return c;
}
char *strcpy(char *source, char *dest)
{
char *ret = source;
while ((*dest = *source) != 0)
{
++dest;
++source;
}
return ret;
}
Exact same function, different names, the second one is way
easier to understand IMO.
Neither are really very good. An assignment embedded in a flow
control statement is an abomination. (But then, so are the
semantics and the interface of the given function to begin
with.)
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.)
--
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