Re: Symbol Name Length (Was: STL Memory leak?)
On Apr 10, 2:53 pm, Arne Mertz <n...@arne-mertz.de> wrote:
James Kanze schrieb:
On Apr 9, 11:21 am, Arne Mertz <n...@arne-mertz.de> wrote:
James Kanze schrieb:
std::list<std::string> optionList;
after some refactoring this is changed to
std::vector<std::string> optionList; //oops.
Encoding the type in the variable's name is duplication of
the type information (and therefore violates the DRY
principle), and it can (and eventually will) lead to
misinformation if the type changes as shown above.
But your example doesn't contain an instance of the type in
name. The object is a list of options; whether the list is
implemented using std::list or std::vector doesn't change
that.
That the options would appear as a List in their graphical
representation is one thing. Still, calling it "list" in the
code would encode the graphical presentation into a variable
that might be suited in a distant module, far away from the
UI-Layer of the application. And it still would be information
duplication, and if the graphical representation changes there
would be no graphical list anymore.
Who said anything about graphical representations? It's a
"list", like in shopping list. According to the American
Heritage Dictionary, a list is "A series of names, words, or
other items written, printed, or imagined one after the other."
The most obvious implementation of a "series of [...] one after
the other" is (in my mind) std::vector, but that's beside the
point.
But anyways, I think that if any programmer reads the word
"List", the first thing thar comes in his mind is the linked
list.
I think it depends on the level you're programming at. If a
container has "list" in its name, yes. But if you're working at
the application level, in contact with users, the first thing
which comes to mind will probably be the everyday meaning.
Of course, this only applies in an English speaking context.
When I was working in Germany, the rule was to use English only
for "technical" terms (like specific data structures), and to
use German for terms from the application domain ("fachlich"),
so we'd have optionsVerzeichnis here, and list would only refer
to the data structure or the component in a GUI.
I'd call that variable an optionList if and only if you have
proven that you need the performance properties of a list
container, and in addition I'd provide a comment about that
and that the container type should not be changed. In any
other case I would call the variable an "optionContainer" or
just "options".
I'd call it optionList if that was the way my users spoke about
it. Container is, in this context, too technical---no user
would ever use the word in that sense. Options would work, but
the difference between "option" and "options" is very slight,
both in terms of entering and reading the text, and in terms of
gut feeling about the words.
--
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