Statalist The Stata Listserver


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: Making a case for case


From   n j cox <[email protected]>
To   [email protected]
Subject   Re: st: Making a case for case
Date   Tue, 06 Feb 2007 22:29:06 +0000

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/



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