tag:blogger.com,1999:blog-347891252975163541.post2179134953483963795..comments2023-05-02T05:20:29.838-07:00Comments on On Coding Style: Short Circuit StatementsAndrew Minerhttp://www.blogger.com/profile/02245034550316893904noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-347891252975163541.post-20978739789259972772009-02-17T09:45:00.000-08:002009-02-17T09:45:00.000-08:00Thanks for the feedback! I think the point you're...Thanks for the feedback! I think the point you're making applies when there's some utility in knowing exactly which conditions were violated (e.g. validating user input from a form, or in testing a variety of use cases). However, in the vast majority of programming, one doesn't need to verify each of the preconditions, one simply needs to know that any *one* of them has been violated. Depending upon which context the last example is used, it may fall into one or the other of those two categories.Andrew Minerhttps://www.blogger.com/profile/02245034550316893904noreply@blogger.comtag:blogger.com,1999:blog-347891252975163541.post-26553170673277887272009-02-15T23:48:00.000-08:002009-02-15T23:48:00.000-08:00While I agree with this post in general, there are...While I agree with this post in general, there are counter examples that show that short circuites are not always a good idea.<BR/><BR/>Consider Andrew's last example. If the first precondition is not met, there's some value in continuing execution past that point. You can, for instance, verify the other preconditions. An IllegalArgumentException is more valuable if it lists all the arguments that are invalid, not just the first.<BR/><BR/>More broadly, this issue comes up all the time in software testing. A given test may pass or it may fail for any number of faults. If a test is short circuted to stop on the first fault it finds, it leaves other faults undiscovered. If a test can uncover more than the first fault, that's a good thing, and short circuiting is not preferable.<BR/><BR/>One may argue that the validation of arguments could be abstracted into another method and that a complex test could be split up into simpler tests that verify fewer conditions. This idea, though, just pushes the same issue of short circuiting into a different level of abstraction.<BR/><BR/>Still, these cases are exceptions, not the rule. Most software is not written like tests.rathbone1200cchttps://www.blogger.com/profile/04056364776051441415noreply@blogger.comtag:blogger.com,1999:blog-347891252975163541.post-76313947844888574882008-10-13T01:31:00.000-07:002008-10-13T01:31:00.000-07:00Haha, I was just going to comment that radoshi mad...Haha, I was just going to comment that radoshi made his exception point when I first started at Pelago and I thought it was a great argument against the single return statement paradigm (at least in Java).<BR/><BR/>Also, I think Andrew's point holds even for languages like C. I prefer checking the conditions up front to layering 'if' statements. It's probably not a coincidence that layered 'if' statements contribute to function points when calculating code complexity.Anonymoushttps://www.blogger.com/profile/05225862148457814516noreply@blogger.comtag:blogger.com,1999:blog-347891252975163541.post-40734275201772004162008-10-13T00:25:00.000-07:002008-10-13T00:25:00.000-07:00Single return values may have been somewhat reason...Single return values may have been somewhat reasonable in languages such as C where there are no exceptions. In languages such as C++ (with exceptions turned on) and Java, you have many, many hidden return paths anyway, and thus the argument that a single return statement makes the flow more readable doesn't hold at all. Even more reason to setup your preamble and do all the error checking up front, thus asserting what you believe are truth values later on in the function.Anonymousnoreply@blogger.com