A while ago I suggested a particular do-file architecture that seemed to work well for me at the time. The post is here. That architecture still works fine, but an obvious improvement suggested itself since I proposed it. I've been finding that some jobs that I had encapsulated in programs are so ubiquitous that I [...]

I just made a couple of changes to this theme's style sheet. I wanted a slightly wider page in order to accommodate longer lines of code. I needed it because some code lines in my Dummy variables post ran over when rendered in IE and Opera. If you cut and pasted the code, errant end-of-line [...]

I've gone through several iterations with my idea of best do-file practices, and I'm sure I'll go through some more before I retire. But right now, here's where I stand: My do-files start with a handful of header commands that I found useful at various times. They might look something like this: clear set more [...]

There's apparently a programming principle going by the acronym DRY -- Don't Repeat Yourself. Somebody needs to teach it to Stata users. See, Stata is so flexible and easy to use that it's perverse in a way. Take for example the ability to generate new variables on the fly, either in interactive mode or wherever [...]

Most Stata commands are programs written in Stata's ado-file language; they are saved as .ado files that you are free to browse. For example, on my Windows XP machine the guts of the simple describe command are here: C:\Program Files\Stata10\ado\base\d\describe.ado. Stata will let you write your own ado-files and treat them as first-class citizens of [...]

If you right-click on a do-file under Windows XP, you can either open it or edit it. Opening it means that Stata will launch and attempt to execute it. The editing, by default, will also trigger a Stata launch, under the assumption that you want to edit the do-file inside Stata's own do-file editor. That [...]