>From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@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.willi...@thomsonreuters.com> wrote: >> >> On 2/15/11 4:35 PM, "Gabor Grothendieck" <ggrothendi...@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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel