From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-project.org]
On Behalf Of Gabor Grothendieck
Sent: February-15-11 6:10 PM
On Tue, Feb 15, 2011 at 5:43 PM, <Ken.Williams at thomsonreuters.com> wrote:
On 2/15/11 4:35 PM, "Gabor Grothendieck" <ggrothendieck at gmail.com> wrote:
I think the real good programming practice is to have a single point
of exit at the bottom.
NB: I am drawing on my experience with C++ and Java, as I have 10x as much
experience with them as I do with R)
It is often not practicable to use a single point of exit. I routinely
have checked all the requirements/assumptions of my code at the beginning,
to ensure error conditions do not arise once the code that does the real
work gets started. That means that there is as least one exit point between
the beginning of my checks and the beginning of my code that is doing the
real work; often more. These exits generally include construction of an
error condition object with the details of what the error is and why it
happened. (but that is my high performance C++ code, and Gui code written in
Java).
I disagree, it can be extremely useful to exit early from a function. ?
It can also make the code much more clear by not having 95% of the
body in a huge else{} block.
If that is the case then the routines may be too large. One of the
purposes of this widely practiced principle is to encourage modularity.
This I'd agree with, to an extent. I routinely try to keep my functions
short enough to be able to see the whole thing without scrolling. This
means I break large tasks into a number of small ones, implemented in
functions that can be inlined. And of course, such small functions make
writing complex conditional blocks much easier and it makes them much more
readable. Thus, if you looked at my C++ code, you'd find a large number of
smaller functions with a single exit, and a small, but significant, portion
of my functions are a bit longer with multiple exits.
Also achieving code coverage can be simplified when using single point of
return rather than multiple points of return.
This is an issue only if your code is badly designed spaghetti code. if
your function is that long, it will be a nightmare to write decent unit test
that test all possible paths through the code, let alone those tests
required to verify that the result it produces is correct. But if you have
ensured that all your functions can be viewed on your screen without
scrolling, it is easy to see all exit points, and write unit tests for each.
The functions that test for conditions that can produce errors often form
the basis of the unit tests needed for testing every possible exit point
(basically killing two birds with one stone). This is relatively simple if
handled right, with a good eye for detail.
One of the things I would point out is that such generalities can be useful
in introducing young people to programming, but it is wise not to be too
dogmatic or generalize too widely.
Cheers
Ted