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: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: "Robert Martin" Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: <6skhpr$459$1@hirame.wwa.com>#1/1 X-Deja-AN: 387288634 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> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: WorldWide Access - Midwestern Internet Services - www.wwa.com Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-02T00:00:00+00:00 List-Id: 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. >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) >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. > >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