Statalist The Stata Listserver


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: RE: accessing a variable's value WRT its attached value label


From   Phil Schumm <pschumm@uchicago.edu>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: RE: accessing a variable's value WRT its attached value label
Date   Thu, 30 Mar 2006 03:23:44 -0600

On Mar 29, 2006, at 4:13 PM, Nick Cox wrote:
The question in return has to be: readable by whom, or more precisely by what class of program reader? what can be assumed of their Stata experience and competence?

Excellent question -- I should have been clearer. I was actually referring both to myself and to a fairly large group (~6-12) of Stata users, ranging in experience from novice to fairly advanced (but none experienced in writing his or her own ado files or, perhaps more informatively, none who has picked up [P]). But your point is well taken; what might be considered readable may well differ between different groups of individuals.

I guess what I was really trying to avoid was the inline expansion of an extended macro function; in my experience, many users find this a much bigger jump than just learning how to use a simple macro (e.g., within a -foreach- loop). This is especially true with the second colon and/or if you throw in additional levels of nesting, e.g.

foreach var of varlist var1 var2 ... {
count if `var' == "yes":`:val l `var''
}



You don't say anything about comments. If inscrutable code is your concern, tuning a comment to give an explanation at the right level is the simplest thing.

Absolutely, though your phrases "tuning" and "at the right level" are pregnant with implications. As you know, good commenting style is difficult for many programmers to learn, let alone people who code only very occasionally. Moreover, too many comments (and/or comments which are excessively long or poorly crafted) can actually decrease overall readability, and in no case is commenting a substitute for writing tight, well organized code. Nonetheless, part of my concern in this case was that the most inexperienced individuals in the group at least be able to look at the code and get some sense of what is going on, and a brief, well-written comment at or near the command(s) in question would certainly facilitate this.



1. As a Stata user who also writes programs, I find the use of a local macro and of an extended macro function unthreatening, but I still have to work a smidgen too much to realise that

`: val l y'

is a minimal abbreviation of

`: value label y'

Having also worked with highly concise languages, such as J, in which almost all primitives are one or two characters long, I have to say that readability does often hinge on avoiding minimal abbreviations.

Thanks for this reminder. Although I'm not among those Stata users who write -g- for -generate- (personally I prefer -gen-), I must confess that in some cases I've gotten in the habit of using minimal abbreviations in other contexts without really thinking, partly, I guess, based on a rather unconsidered belief that a shorter line was in some sense "cleaner" (i.e., less "ink") and therefore better. However, I agree that the second option above is certainly more readable than the first, and am inclined to try and retrain myself away from my current behavior (at least in some cases).



2. The construct

"label":valuelabelname

is prominently documented, but my impression is that it is fairly rarely used.

I agree, certainly if not among active members of Statalist, then among the majority of "regular" users. Moreover, unlike inline expansion of extended macro functions, I would argue that this construct should be learned (and used) by everyone because of its potential to help avoid simple mistakes (e.g., forgetting whether 0 is no and 1 is yes, or 1 is yes and 2 is no, or wait, wasn't that...).

As always, thanks for your words of wisdom.


-- Phil

*
* 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/




© Copyright 1996–2020 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index