st: re: What is good programming practice in Stata?

[Christopher Baum <baum@bc.edu>]

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