Re: if clause
- From: Clever Monkey <clvrmnky.invalid@xxxxxxxxxxxxxxxxxxx>
- Date: Mon, 30 Oct 2006 11:04:02 -0500
Ancient_Hacker wrote:
rogz wrote:This is certainly a common opinion, but the code I maintain embraced the other approach: if you have special cases while setting up the main meat of the function that suggest that continuing makes no sense, then bail out early.
0: if (out < 0)
1: return (fileError)
2:
3: if (permission < operator)
4: return (permissionError)
5:
6: if (data.len() <= 0)
7: return (dataError)
8:
9: write(out, data, data.len)
There are several disparate issues with this code and the original
writer wasnt very good at pointing them out. Here's my view:
(1) Some people think a function should have just ONE clear exit
point, at the bottom. I realize that can get a bit long-winded, but it
can make the code MUCH CLEARER, much easier to set breakpoits, much
easier to add code you're SURE will get run every time. Multiple entry
points went out with FORTRAN II, why do we still have multiple exit
points in this 21sh century?
We have a whole runtime-enabled logger system so, as long as you log the entry and exit, debugging is easy and the code is easy to read.
Once we get into the main logic for the function we usually have the usual assortment of breaks to ensure that there is only one more exit point to be had.
The other approach I've seen is to have all the special cases handled by a number of "goto early" or "goto error", where the return is normalized and control short-circuited to the exit point.
All of these approaches make sense under the right circumstances, but this maintenance drone prefers code that can be easily read, top-to-bottom, to figure out what it is *supposed* to do so the bugs are easier to find.
Freeing up my cognitive energy by being able to discard early control paths as I go really helps me solve some obscure problems. It also allows one to say with accuracy that some variable or parameter is in some known range (e.g., some value is or is not null, or some parameter cannot possibly be 0, &etc.) after some specific point.
I'm speaking as someone who might not be able to run a debugger on live code (I maintain chunks that are compiled with older compilers that have crufty debuggers that don't run on later releases of Windows, for example).
.
- References:
- if clause
- From: rogz
- Re: if clause
- From: Ancient_Hacker
- if clause
- Prev by Date: Re: how to use bit operation to do \sqrt(n)
- Next by Date: Re: if clause
- Previous by thread: Re: if clause
- Next by thread: Re: if clause
- Index(es):
Relevant Pages
|
