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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no 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: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public From: Mike Spille Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: <35EDA767.E872948E@tisny.com>#1/1 X-Deja-AN: 387329791 Content-Transfer-Encoding: 7bit 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> <6skcr2$i4o$1@nnrp1.dejanews.com> <6skhpr$459$1@hirame.wwa.com> Organization: Transaction Information Systems Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: Robert Martin wrote: > > adam@irvine.com wrote in message <6skcr2$i4o$1@nnrp1.dejanews.com>... > >In article <6simjo$jnh$1@hirame.wwa.com>, > > >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. > > I agree with this. It's the converse that I don't agree with. > > Yes, code must be readable to be maintainable (whatever "readable" means). > On the other hand, code that is readable is not necessarily easy to > maintain. > > Simple example: the file 'error.h' is loaded with lots of #defines that > specify all the various error codes that our functions can return. > 'error.h' is very easy to read, and completely understandable. But > maintaining it is a royal pain because every time we add a new error code, > we have to recompile the world. > An interesting branch from a loop discussion :-) > >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?). > > Think about this for a minute. Wouldn't it be nice if you *could* stick a > line of code at the end of every loop, or at the end of every function, and > be guaranteed that it would be called? For example, have you every had to > put those interesting little print statements into functions: "entering > function x", "exitting function x"? Wouldn't it be nice if you could just > plop those print statement in without having to anlayze each and every > function for multiple returns? > > (Yes, I know we can use RAI for this. But lets pretend that we are writing > in Java, or C) > As an aside...most hideous language proposals I've seen begin with "Wouldn't it be nice if....". The best proposals begin with "I have a strong need for....". I think there is a certain correlation to your above statement.... That said, I'll re-iterate what myself and others have said: your implication is that people should be able to muck with a function without understanding it (e.g. syntactical constructs are enough to tell the tale, and semantics beside the point). I strongly disagree - most of the maintenance goofs I've seen haven't come about due to multiple loop exits or "badly structured code" (whatever that may be) - it's been due to maintenance programmers not taking the time to understand the code. > >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. > > Yes, I agree with this, but only in part. Sometimes you really don't have > to completely understand a function in order to make the necessary > modifications. In those cases, if an se/se style has been adopted, it's a > lot eaiser to understand the control flow and insert the appropriate > statements. Please don't take this as a personal attack, but I hope you never, ever touch any of my code. I would horse-whip any of my guys who "really don't completely understand a function" and made a modification to it. > > > >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. > > No insult intended. However, the "easier to write" justification has been > used in several postings. > > Robert C. Martin | Design Consulting | Training courses offered: > Object Mentor | rmartin@oma.com | Object Oriented Design > 14619 N Somerset Cr | Tel: (800) 338-6716 | C++ > Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com > > "One of the great commandments of science is: > 'Mistrust arguments from authority.'" -- Carl Sagan -Mike