[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From   "Isabelle Deltour" <>
To   <>
Subject   st: RE: re: What is good programming practice in Stata?
Date   Fri, 20 Nov 2009 09:41:11 +0100

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

-----Original Message-----
[] On Behalf Of Christopher
Sent: Thursday, November 19, 2009 5:45 PM
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.


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   |
An Introduction to Stata Programming   |
An Introduction to Modern Econometrics Using Stata   |

*   For searches and help try:

*   For searches and help try:

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