Date: Tue, 19 Sep 1995 16:02:18 -0600 From: Nate Williams <nate@rocky.sri.MT.net> To: Terry Lambert <terry@lambert.org> Cc: nate@rocky.sri.MT.net (Nate Williams), davidg@root.com, hackers@freefall.freebsd.org Subject: Re: Coding style ( was Re: why is this not a bug in namei?) Message-ID: <199509192202.QAA26020@rocky.sri.MT.net> In-Reply-To: <199509192128.OAA10722@phaeton.artisoft.com> References: <199509192049.OAA25811@rocky.sri.MT.net> <199509192128.OAA10722@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > Fair enough. In those cases it is acceptable to return a different > > errno to designate a different error. But, the issue you brought up was > > that it is necessary to use gotos in order to maintain one exit point. > > My point was using gotos to keep one exit point is un-necessary > > obfuscation. > > OK; this deserves clarification. Is it the goto's themselves which you > object to, or their use to ensure a single exit point that is objectionable? If that is the only use of the goto (which you implied in an earlier message) then I feel that the use of gotos is objectionable. Again, I have seen very few cases where gotos improved readability. And, as noted you disagree with my opinion that gotos are inherently evil and should be avoided at all costs. > If the goto's, then in some cases I agree with you, though I find them > the lessor of two evils when choosing between drastically increasing > indentation and using negative logic or adding a single label and using > a goto. This is where we will continue to disagree. My brain and my editor both like parens for separating code blocks. When you throw in gotos my brain has to think differently, ala BASIC. *grin* Note that I also use 4 spaces for indentation, and 4 spaces instead of tabs to get more stuff on the screen. The more stuff I can see on the screen, the better off I will be in seeing overall flow of the system. > This is admittedly a religious issue (like 8 column tabs -- 4 column tabs > would resolve the schizm by reducing the indentation, but it seems that > your pope and my pope agree on 8 column tabs saving an average of 1.6 > characters per line (4 vs. 3 every other line)). > > If you can point to the-one-true-light, I'll follow it. *laugh* > > As I understand it, the specification quoted above was meant to be > > applied to application programs who 'exit'. I used it to show that > > there was no documentation which implied one exit point from a function. > > I'm not sure where you got this feeling from. > > I got it from the need to have known state in and out of a function and > to maintain that state across changes to the function body. > It's difficult to maintain consistency without explicit assertions, and > multiplying the exit points multiplies the chances that you will introduce > an inconsistency when modifying function bodies. True, but adding gotos messes up logical program flow IMHO. > > > If this is a form vs. function argument now, then I have already won, > > > since you also seem to be on the side of function. > > > > No, I'm saying that *IF* you are going to re-write the code, write it in > > such a manner that makes it understandable. > > And I'm saying, adding a goto to an error label is not obfuscating the > code into unreadability. It is clearly an error path and clearly an > exception case. Again, we have a difference of opinion here. > > Let's strive for both form and function. > > I don't believe adding a goto translates a program into Sanskrit. But it un-necessarily obfuscates the code, vs. negative logic and the other forms of indenations you've mentioned above. > Tell you what. I'll teach you how to read a goto. Then you can carry on > when I get hit by a car on my way home some night by some anti-goto zealot. But why should I learn how to do something which is only used in code you write? I like the rest of the sheep will follow the one true way of writing C, which means no gotos. Again, it's getting rather religious and off topic now, so I'll shutup after this. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509192202.QAA26020>