Lee/All,
Nor do I ever use abbreviations. Not knowingly, that is, which is the
entire point. As such, the suggested "set literalvarnames on" would be
an adequate fix, if nothing else, to simply avoid the potential pitfall.
If such a switch is not possible, would it be possible to have Stata set
to trigger a display anytime a varname is interpreted as an abbreviation
of another varname currently being held in memory?
- Glen
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Lee Sieswerda
Sent: Tuesday, February 11, 2003 10:55 AM
To: '[email protected]'
Subject: st: RE: RE: RE: RE: Referring to a varname, leading to errors
Nick,
I'm not sure how useful such a straw poll is, but since you asked... I,
for one, never use varname abbreviations. Perhaps in some deep recess of
my psyche I believe in Murphy's Law and don't want to run into Glen's
problem inadvertantly. So, I would not be against having some way to
toggle varname abbreviations off. But I wouldn't see it as a high
priority. I do, however, use shortcut syntax for variables (e.g., var*,
var1-var15) everyday and would never want that to be changed. Also,
judging by the code snippets on Statalist, I'd say that the vast
majority of users use command name abbreviations, and would never want
that to change either!
And speaking of abbreviation, many thanks to StataCorp for all of those
new aliases that allow a user to abbreviate calls for help (e.g. whelp
reg; whelp tab; whelp inrange; etc.). That is a very useful time-saving
feature.
Lee
> -----Original Message-----
> From: Nick Cox [SMTP:[email protected]]
> Sent: Tuesday, February 11, 2003 1:34 PM
> To: [email protected]
> Subject: st: RE: RE: RE: Referring to a varname, leading to
errors
>
> Glen Waddell
>
> > I suppose the quick reply is, bummer.
> >
> > There is certainly a place for abbreviated command names. My example
> > with respect to varnems, however, is intentionally simple. One must
> > recognize that this issue can lead to costly down time when
> > mistakes are
> > made and must be tracked down. Abbreviated varnames just
> > doesn't seem
> > worth it, and clicking on the varname doesn't help when running
> > do-files.
>
> This seems to undervalue the benefits of what is generally considered
> a feature.
>
> The overall cost-benefit analysis is tricky, in terms of many, many
> minute time savings versus some much longer time working out what went
> wrong more rarely (not to mention those analyses which were not what
> you intended, but you never realised it).
>
> But let's pose a question to Stata Corp and one to users.
>
> 1. Stata Corp
> =============
>
> Suppose a user like Glen doesn't want to be bitten
> ever by this. Imagine that such users can
>
> . set literalvarnames on
>
> meaning
>
> "Listen here, Stata: you are to behave, given my
> input, as if you never allowed abbreviated variable names."
>
> How easy would that be? Would there be side-effects?
> Well written programs that Glen uses, consciously
> or not, should all make use of temporary variables,
> but in practice there may be exceptions.
>
> In practice, perhaps, the issue is Command window input PLUS .do
> files.
>
> 2. Users
> ========
>
> Do you want what Glen wants? Not disallowing all
> variable name abbreviations, which I guess will
> never happen, but being able to set this for yourself
> to avoid what Glen describes.
>
> Nick
> [email protected]
>
> *
> * For searches and help try:
> * http://www.stata.com/support/faqs/res/findit.html
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
