For those interested in the topic, but in a large sense, I found the
book by Long
very informative. Some sections deal with code writing, but it is not
the focus of the book.
The workflow of data analysis using Stata / J. Scott Long.
Hope this helps
Isabelle
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Christopher
Baum
Sent: Thursday, November 19, 2009 5:45 PM
To: [email protected]
Subject: st: re: What is good programming practice in Stata?
<>
Stas said
"Well, if it were possible to have peer review of the code submitted
to SSC or Stata Journal, just like there is peer review of research
submitted to academic journals, we would have better code floating
around; but there are simply no human resources to do that."
I agree with most of the points Stas makes about programming
practices. From my own experience with Stata Journal reviewing as an
associate editor, I have certainly requested (i.e., demanded) authors'
revisions to the code they have submitted with an article. I don't go
through the logic of every line, or demand adherence to particular
programming practices, but if it is sloppy code, that is as
problematic IMHO as sloppy exposition of the theory and logic behind
the code, or the application to an empirical example. I can't speak
for the other AEs and reviewers of the journal, but I would hope they
and the Editors would agree that code accompanying SJ pieces should be
given reasonable scrutiny before acceptance, and be held to higher
standards than code that has merely been placed in the public domain.
Like any standard of practice, the materials in the SJ fall short
sometimes; but then so does official Stata code sometimes, despite far
more exhaustive internal review and testing. Bugs happen.
With regard to the SSC Archive's contents, my official stance is that
I do not review code, and that whether it does anything sensible as
described in the help file is purely the author's responsibility. That
said, there have been several occasions in the past couple of months
when I have sent code back to the authors and told them I could not
accept it in the form submitted, as a cursory glance at the code
revealed quite unacceptable programming practices (e.g. using preserve/
restore in a loop over a varlist). In each of these cases, there was a
straightforward way to write the code in a way that avoided such
practices, and in most cases authors responded with revised code.
Acceptable code doesn't have to be beautiful, or elegant, or well-
documented, although all three of those things are helpful for its
further maintenance and reuse. Points made in Roy's postings regarding
extensibility are also good: quick and dirty code is rarely extensible
or usable beyond its original purpose. But there are ways in Stata to
avoid egregious practices (e.g., generating hundreds of scalars as new
variables when scalars would suffice), and user-programmers can always
learn from the masters---either from official Stata code, or from code
written by experienced and careful user-programmers who have developed
useful routines.
Kit
PS> The discussion of programming style in my book ISP (sections 2.8
and 11.14) was borrowed and edited, with permission and appropriate
attribution, from Nick Cox's writing on the subject.
Kit Baum | Boston College Economics and DIW Berlin |
http://ideas.repec.org/e/pba1.html
An Introduction to Stata Programming |
http://www.stata-press.com/books/isp.html
An Introduction to Modern Econometrics Using Stata |
http://www.stata-press.com/books/imeus.html
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
