I tend to code with return(), at least in development, because I've once
stepped in the
cowpad of
ans<- list( )
then attr(ans ....)
and forgot to do another
ans
so got only part of what I wanted. Perhaps its just my thinking style, but I
agree with
some others who suggest that it's not such a bad idea to be explicit about what
one is
doing. I prefer pedestrian code that I can understand easily and quickly
fix/modify rather
than highly optimized and uncommented brilliance that I cannot reuse.
Given the overhead of return(), I'll likely switch to
ans # return(ans)
to make my programs clear, especially to non-R folk migrating in.
I have also been writing optimization functions. Modularizing might be a nice
student
exercise, as well as avoiding early return()s, but Canada isn't wide enough for
all the
indents of the else clauses when methods crash at different stages and we want
to return a
very simple structure with partial data etc.
Reminds me of the great "GOTO" debate some 30+ years ago.
JN
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
