Naturally I agree that good ideas must come from
somewhere, so let us hear yours, and welcome.
Equally, I put up the opposite arguments, not
that the matter is necessarily adversarial, but
that may help fix ideas.
Somewhat similarly, I hoped to spark some debate on
Stata programming style by writing first a help
file -- still downloadable from SSC as -stylerules- --
and then writing up an extended version as a paper
in Stata Journal 5(4): 2005.
Not much happened, and I don't know whether anyone changed
their style as a result. One Stata friend and list
stalwart still programs as if he was writing code
on the back of the last used envelope in the world.
But then I can change my mind too. I've surprised
myself by warming once more to #delimit ;. A code
fragment like
// graph
scatter `yshow' `xshow' `gif', ///
ms(O) yti(`"`yaxtitle'"') xti(`"`xaxtitle'"') ///
yla(`axlabel' nogrid notick) `stretch' `dots' ///
///
|| pcarrow `yshow3' `mean' `yshow2' `mean', ///
msize(medlarge) barbsize(medlarge) `fulcrum' ///
///
|| rspike `min' `max' `yshow2', hori `beam' ///
legend(off) `byby' `options' ///
///
|| `addplot'
// blank
I would now be tempted to rewrite as
// graph
#delimit ;
scatter `yshow' `xshow' `gif',
ms(O)
yti(`"`yaxtitle'"')
xti(`"`xaxtitle'"')
yla(`axlabel' nogrid notick)
`stretch'
`dots'
|| pcarrow `yshow3' `mean' `yshow2' `mean',
msize(medlarge)
barbsize(medlarge)
`fulcrum'
|| rspike `min' `max' `yshow2',
hori
`beam'
legend(off)
`byby'
`options'
|| `addplot' ;
#delimit cr
// blank
although I don't expect everyone to like it. Nevertheless
I think it is more readable in a program file, and much
easier to edit too.
The story of -for- is more
complicated than many people may now know. (If you
don't know, this is nothing to do with Mata's -for- in Stata 9.)
The old -for- is still there and working, but you'll
have to search hard for proper documentation (in the
Stata 6 manuals, for example). -for-
started out simple, was made more complicated
again, then made much more simple in successive versions --
and then killed off, or more precisely made less visible.
It got many fans, but burned many fingers, and little
cottage industries sprang up documenting the non-documented
features, explaining on Statalist why people's -for-
statements went bizarrely wrong, and writing FAQs to the
same effect. In one version of history, it was a very good
bad idea.
But in significant ways the old -for- was more powerful than
the present -foreach-. You could do things like
for X in var _all \ Y in new var1-var12 : rename X Y
which now require more complicated code like
local i = 1
foreach v of var _all {
rename `v' var`i'
local ++i
}
and even that does less than the -for- did. One moral
is that a language can be too complicated for anyone's good.
I worry a bit that SMCL is too complicated for casual users:
the uptake of Stata 9 additions even among fairly serious
user-programmers has been muted.
Nick
[email protected]
David Elliott
Thank you, Nick, your point on indentation convention is well taken.
I use a tabwidth of only 2 spaces in my editor, a habit I acquired
when writing deeply nested xhtml to prevent exactly the "march off the
right side" of which you speak. Consequently the additional indent on
the else doesn't over-indent my code in practise. However,
semantically, the if and else are at an equivalent level and should
share the same indent, so I may have to reconsider my habit in light
of your assertion that it may be less clear to other Stata
programmers.
While I agree with the assertion that complex code is complex, i
believe an alternative to deeply nested ifs would be welcome to many,
I think, and only wanted to spark some discussion. We have seen the
-for- construct mature in functionality from the original for to
today's -foreach- and -forvalues-. Before they were introduced
someone like me must have said, "I wish...".
<snip>
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
