From nashjc at uottawa.ca  Wed Feb 16 19:21:56 2011
From: nashjc at uottawa.ca (Prof. John C Nash)
Date: Wed, 16 Feb 2011 13:21:56 -0500
Subject: [Rd] return(); was  Suggestions for "good teaching" packages
In-Reply-To: <mailman.19.1297854009.22220.r-devel@r-project.org>
References: <mailman.19.1297854009.22220.r-devel@r-project.org>
Message-ID: <4D5C15C4.9070806@uottawa.ca>


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



[Rd] return(); was Suggestions for "good teaching" packages
Prof. John C Nash