Here is one answer: No. I'd underline that that assertion
is partly a judgement based on taste.
In my experience, complicated logic is complicated
logic and the syntax for applying that is secondary.
I can't comment quantitatively on efficiency, but my guess is
that the issue is trivial unless these blocks are encountered
repeatedly within some larger loop.
Layout (consistent indentation especially) is more
important. (There is no contradiction, of course.)
Admittedly, it is sometimes necessary to sacrifice the Stata
convention of one tab being 8 spaces unless you can bear code
marching off to the right.
Also, if there is some risk of losing sight of the wood
for the trees, then erecting subroutines can make for clearer
code. My own code is not especially full of examples, but
there are plenty enough in Stata's own ados.
I strongly endorse your incidental remark on text editors.
Stata's own do file editor has such matching, so no one
is deprived. But I find your convention on where you put closing braces
creates code that is difficult to read, but you would probably
say the same about the convention I (and most Stata programmers)
follow.
if #1 {
something
}
else {
if #2 {
something else
}
else {...
I would lay out like this:
if #1 {
something
}
else {
if #2 {
something else
}
else {...
Nick
[email protected]
David Elliott
< snip>
(Using a text editor with brace/parenthesis matching is a real boon to
avoiding mistakes.)
My real point in posting this code is that this whole exercise in
keeping track of my multiply nested elses would have been a lot
simpler if Stata had the equivalent of a -do case- command as a number
of other languages do. The -do case- construct continues until a case
has been satisfied which then passes program execution to the point
following the close of the case block. Instead of:
if #1 {
something
}
else {
if #2 {
something else
}
else {...
one could use something in the form:
docase {
case #1 {
something
}
case #2 {
something else
}
otherwise {
and something else again
}
} //end case
I'd be interested to know if anyone else has had occasion to long for
such a construct within Stata to handle the gnarly mess that occurs
when one must handle a large number of nested else- ifs. The
immediate benefit would be more readable code. I understand from
working with Foxpro that the do case construct is faster to execute
than multiple ifs, so there may be a potential for performance
improvements as well, especially if this occurs within a loop.
*
* 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/