Re: How to name variables in a program?

Jens.Toerring@xxxxxxxxxxxxxxxxxxx wrote:
> spinoza1111@xxxxxxxxx wrote:
> > Alf P. Steinbach wrote:
> >> * Paul Hsieh:
> >> > int dbPop3MsgHdrGet (struct pop3Db * db, struct mimeMsgHdr * msg);
> >>
> >> It's difficult to say whether this is irony or just misguided.
> >>
> >> Presumably it's for C?
> >> Have you tried to _pronounce_ those, uh, "names"?
>
> > Why is this important?
> > Does any one read programs out loud?
>
> > I would say that the desire to "pronounce" names comes from Derrida's
> > syndrome: the rage to return to speech and to jettison writing. [...]
>
> Complete drivel from someone who is obviously an armchair programmer
> at best. Nobody sane is able to parse stuff like "LPCTSTR" or
> "dbPop3MsgHdrGet" correctly when reading a program or seeing the
> difference between e.g. gibberish like "LPCTSTR" and "LCPTSTR".

Ok, now hang on. First of all don't associate the convention I am
espousing with hungarian.
The real problem with "LPCSTR" meaning "long pointer to C string"
nonsense is that it doesn't mean anything useful even *after* you have
decoded it. People already know that char * means "pointer to string",
and we know that i, j, ... are integer loop or array indexes. What we
need naming conventions for are for things we don't know, like "where
is this defined?" or "what does this act on?" without losing your place
by using some tool to look it up.

dbPop3MsgHdrGet is different. You immediately know that its an
attribute read function of some kind (Get) its been defined in a module
called db, or a submodule of db called pop3, and the thing we are
reading is a "message header". So its an explicit encoding, that lets
you know exactly what it is. In C++ it would probably look something
like db::pop3::msg->getHdr() which is not drastically different.

The other advantage of my scheme is that when you ASCII sort the
symbols, they make some sort of sense and look fairly organized
anyways. This is one of the quibbles I have with typical C++ usage --
since you use the "using <namespace>" context mechanism (and can have
multiple such nested "usings"), the namespace that a symbol is actually
part of isn't explicitely associated with the symbol in the source.
I.e., I like C++ namespaces, but usage of "using" should be minimized.

> [...] We are all trained to read words, not more or less random
> sequences of characters. That's what makes HN that horribly
> annoying:

We are also trained to read natural language as well. Computer
programs can never deliver that degree of readability anyways. On the
flip side, look at the evolution of the english language itself.
Common writing includes abbreviations like, AKA, IMHO, Re:, cc, FWIW,
etc. You can look at chatroom speak for more extreme examples. In
fact even beyond conventions it leads people to write abbreviations on
the fly depending on context -- like using "HN" to mean Hungarian
Notation. (See quote above!)

Encoded sequences are not the problem, in fact I would claim there is a
large attraction towards them, ... its the substance of what they are
encoding that matters.

> [...] you can't
> recognize what's meant when you read it and 90% of the time (see, I
> also can make up my own statstics as I go) type information is either
> not important or clear from context when variables have reasonable
> names - you pay for information you don't need most of the time with
> making the whole source code much harder to read.

Its just the redundancy and lack of relevant descriptive context that's
the problem. Even in optimal situations, hungarian notation simply
doesn't offer you enough value to be worth the cost of adopting the
scheme.

> [...] And since everybody
> is prone to make typing errors it's also much more difficult to spot
> typos when using variable names that look like line noise instead of
> names that can be read easily. A misspelt word often immediately
> comes to your attention, but when you type "LCPTSTR" instead of
> "LPCTSTR" you will have problems to see the difference, even when the
> compiler explictely tells you that there's something wrong with the
> variable (let's hope you're using a language that requires a defini-
> tion of a variable before it can be used and doesn't silently create
> a new one with the misspelt name...)

I agree, but this problem is really just an exacerbation of C's weak
typesystem. Any pair of points can magically coerce without anyone
being the wiser.

> Just have a look at the source code in what seems to be the original
> paper by Simonyi at
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs600/html/hunganotat.asp

The "rank this article" scores are hilarious. People rate as either a
1 or 10. I wonder which are MS internal people, and which are people
outside of MS. :)

--
Paul Hsieh
http;//www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: Question on LSP
    ... not have to be explicit attributes, ... Since objects in memory usually don't move, the language can largely hide the identity mapping. ... My issue here is that whatever semantic meta model the language uses, there must be some way for the developer to unambiguously express the OOA/D is-a semantics for some problem space entity. ... Note that the language allows us to use a name like 'T' on the reference as a mnemonic so that the developer can keep track of what is happening with the indirection. ...
    (comp.object)
  • Re: The definition of the Standard variation of British English
    ... English" - anything goes - doesn't it? ... standard language. ... conventions and the limits imposed by the degree of clarity and exactness ...
    (alt.usage.english)
  • Re: RFCAS - Configuration segments in the San language
    ... > San is a new language that I am developing the specifications for. ... > finding source code in other files, ... > and does not work well with code supporting alternate features. ...
    (comp.programming)
  • Re: The definition of the Standard variation of British English
    ... and norms in language that very closely conforms to the extant standards ... precision and elegance possible given the skills of each party in those ... conventions and the limits imposed by the degree of clarity and exactness ... None of that is to say that English, or any language, is or should be ...
    (alt.usage.english)
  • Re: Programming to Beat the Odds in Gaming
    ... black-red) strategy is no better than straight-red or straight-black. ... don't even know language it is written in. ... In this pseudo-language, a program consists of functions, and a function ... I still haven't seen your source code. ...
    (comp.programming)
Quantcast