Date: Tue, 19 Sep 1995 14:49:50 -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: <199509192049.OAA25811@rocky.sri.MT.net> In-Reply-To: <199509192028.NAA10566@phaeton.artisoft.com> References: <199509191905.NAA25538@rocky.sri.MT.net> <199509192028.NAA10566@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > 9 items in short term memory simultaneously. That would be why phone > > > > > numbers are 7 digits. > > > > > > > > > > I'm not even taxing the low end of the study participants. > > > > > > > > What this has to do with you using goto's I have no idea. > > > > > > It shows that David's complaint about 3 goto's is religious, and not as > > > he said a result of battling obfuscation. > > > > Huh, you lost me here. > > Look. For humans to become confused, you need to stuff more than 5-9 > things in front of their face in order to decouple their short term > memory. To put this in computerese, humans have a 5-9 item cache. If > you don't go over 5, then you don't bust the cache on even substandard > humans (manufactured by Cyrix?). > > David's complaint is that 3 goto's obfuscate things. > > In reality, >5-9 goto's obfuscate things (by overflowing a human's cache). > > He pulled the number 3 out of the air based on his religion in this regard. No, I think that *ANY* # of gotos obfuscate things, but sometimes a single goto is less obfuscation (is that a word?) than other choices. > > > Getting to the one function exit the way the BSD code is currently > > > written requires a goto. > > > > If the code *needs* to be written that way, then I can see your point, > > but I don't see that as part of KNF. The only thing even mentioning > > exits implies that you can have multiple exits in any function. > > > > I quote: > > /* > > * Exits should be 0 on success, and 1 on failure. Don't denote > > * all the possible exit points, using the integers 1 through 300. > > */ > > exit(0); /* Avoid obvious comments such as "Exit 0 on success." */ > > This is a problem in the general applicability of the specification. Many > kernel functions return an errno value. 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. > Either this specification doesn't apply to that code, or that code is in > fact flawed. Pick one. 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 look forward to your and David's patches to the following functions, > > > and to the functions not in these two subdirectories that have the same > > > "goto infestation problem": > > > > AFAIK, we are discussing new code re-writes, not changing already > > existing code. Re-writing all of the existing code is a worthy task, > > but there are much worthier tasks that need to be done. > > 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. Modifying the code from a dis-functional but readable form into a functional but un-readable form is not progress. First of all, someone has to own the code in the CVS tree, and if they don't understand it at some level, they are not going to commit it. Second of all, IMHO most of the bugs in the system exist in areas where the code is not extremely readable. I've seen too many systems where 'form' was not followed and functionality ruled, and when the person who implemented the 'functionality' left the code continued to live on bugs and all since no-one else understood it. Let's strive for both form and function. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509192049.OAA25811>