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

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

From   Christopher Baum <>
Subject   st: re: What is good programming practice in Stata?
Date   Thu, 19 Nov 2009 11:44:43 -0500

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:

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