From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: adam@irvine.com Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: <6skcr2$i4o$1@nnrp1.dejanews.com> X-Deja-AN: 387248006 References: <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <6r1glm$bvh$1@nnrp1.dejanews.com> <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com> <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <35f51e53.48044143@ <904556531.666222@miso.it.uq.edu.au> <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com> <6simjo$jnh$1@hirame.wwa.com> X-Http-Proxy: 1.0 x14.dejanews.com:80 (Squid/1.1.22) for client 192.160.8.44 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Wed Sep 02 21:20:34 1998 GMT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada X-Http-User-Agent: Mozilla/3.0 (X11; I; Linux 2.0.18 i586) Date: 1998-09-02T00:00:00+00:00 List-Id: In article <6simjo$jnh$1@hirame.wwa.com>, "Robert Martin" wrote: > In any case, I note that in this thread nearly every article that advocates > multiple exits evokes either readability, complexity, or naturalness as the > justification. I contend that these are highly subjective things, that are > not shared by all programmers alike. Indeed, what is readable, natural and > simple to me, may be opaque and convoluted to you. I also contend that > these issues are somewhat emotional, as evidenced by the terms such as > "twist", "warp", "bend", "religious argument", etc. that have also been used > in this thread. > > Finally, I contend that the factors in favor of using a > single-entry/single-exit style are, on the other hand, quite concrete and > demonstrable. It has been shown that adhering to a structured style > facilitates both resource management and error processing. It has also > been shown that a multiple exit style is vulnerable to redundant code, and > code for recovery of state. > > So, it seems what we have here is "gut feelings" warring against empirical > data. I agree with the first quoted paragraph, but I wonder about the "empirical data" part. So far, on this thread, I haven't seen any empirical data at all, aside from the one study Matthew quoted. Instead, I've seen lots of theories and explanations for why style X is better than style Y. Some have sounded pretty logical, and others seem to have no connection to reality. Even so, all of them seem to be little more than speculation. Someone might say, "Putting all the predicate information at the top of the loop leads to better code", but where's the empirical evidence that this is the case? I mean, we could come up with all sorts of logic about why doing this should be better, but without some sort of study, our logic is based on assumptions about what *seems* like it should be more maintainable, assumptions that may or may not hold water. At best, these assumptions may reflect the poster's personal experience; but since not everyone thinks the same way, an assertion based on someone's experience may not be all that useful. One person may find code style X easier to deal with than Y, but another might find X to be more difficult. I've noticed this in some of the short examples posted, where one person posts something they think is quite clear, but I've had to stare at it for a long time to figure out what the code was supposed to do. This may be because all of us programmers have had difference experiences working with different kinds of code, so that a programming idiom that one programmer is intimately familiar with may take some effort for a different programmer to figure out. Anyway, as someone who has been pounding keyboards for 20+ years, I've had a lot of experience at noticing what kinds of coding techniques lead to more or fewer problems later when I try to maintain my code, and what techniques in other peoples' programs make them easier or more difficult to work with; still, I wouldn't call my own conclusions more than "gut feelings". Certainly, I haven't come close to the standards required to ensure that my conclusions are controlled for other factors, free from personal bias, etc., that would enable me to call my experiences "empirical data". At worst, the assumptions behind arguments for style X or Y are based on abstract ideas that we have no reason to believe has any actual correlation with maintainability. This was my original complaint about some of the arguments against GOTO, but it applies equally to the other arguments about "multiple exits", "continue" statements, etc. Some of these arguments strike me as someone struggling to come up with reasoning that supports a viewpoint that they believe in but don't have clear logical reasons for---i.e. a viewpoint they have no more than a gut feeling about. It's no wonder some of us look at these arguments as "religious wars". So, rather than gut feelings warring against empirical data, the whole thread appears to me to be gut feelings warring against other gut feelings. > I can understand why the gut reaction is so strong; multiple exits > are *eaiser* to write; and are, for some, easier to read. But those are not > the only, or even the most important, criteria for evaluating the quality of > a design. Maintainability is an issue too, and sometimes an overriding one. I agree that ease of writing doesn't correlate well with maintainability, but ease of reading seems to be a very important factor. I don't see how code can be maintainable if it's not easy to understand. If it's relatively difficult for someone to understand what's going on, it has to be relatively easier (it seems to me) to modify the code in a way that screws things up. For example, it seemed that one of your arguments about why fractional loops are worse is that you could add statements to the end of the loop and be assured that they would be executed every time. I don't see this. It seems to imply that a programmer should be able to just stick statements at the end of the loop, without understanding what the whole loop does, and be assured that they will be executed every time (how could this argument possibly make sense if the programmer fully understands the loop's control structure?). But my experience is that if I try to add code to the end of a loop without completely understanding what's going on, I'm just as likely to add bad code to a loop without multiple exits than to a loop with them. I think this argues that ease of reading is, in essence, the most important criteria, since it can't be separated from maintainability. Finally, a lot of people on this thread have tried to explain why they find multiple exits easier to read and understand, but you seem to be implying that they're doing this just to justify writing code that's easier to *write*. I don't see this at all, and I think it's an unwarranted insult. > In the end, the decision to use a structured style is a tradeoff. There are > benefits, and there are costs. And there are certainly situations in which > the costs outweight the benefits (e.g. quick an dirty programs that have > short lifetimes and require little maintenance during their life). It is > also true, however, that for a very large set of circumstances, the benefits > outweigh the costs. I agree, as long as "structured style" is loosely defined. Code that has any structure at all is easier to read than code that doesn't. And sometimes it's faster and easier to write unstructured or carelessly-structured code, but this should be avoided when possible. My own feeling is that once a programmer makes readability a priority, and follows certain general principles we can all agree with (e.g. break the code down into relatively small segments that have a clearly defined purpose, and use comments), the programmer will write code that's more maintainable. The programmer has to rely on judgment to decide what the best style is in a particular case, and of course more experience produces better judgment. But I just haven't seen any compelling evidence that, for a programmer who understands the importance of readability and has good judgment, any particular style will be preferable to any other particular style (occasional GOTO's vs. avoiding them like the plague, single-exit vs. multiple-exit, using return's in the middle of your procedures, etc.). I just don't see that we have enough empirical evidence to support any such conclusion. -- Adam -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum