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: 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: "Robert Martin" Subject: Re: Software landmines (loops) Date: 1998/09/02 Message-ID: <6ske0c$16k$1@hirame.wwa.com>#1/1 X-Deja-AN: 387269824 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> <6sf87j$47n$1@hirame.wwa.com> <6sh6ic$o8p$1@nnrp1.dejanews.com> <6shhcq$lid$1@hirame.wwa.com> <6sk59r$8e6$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: sureshvv@hotmail.com wrote in message <6sk59r$8e6$1@nnrp1.dejanews.com>... >In article <6shhcq$lid$1@hirame.wwa.com>, > "Robert Martin" wrote: >> >> sureshvv@hotmail.com wrote in message <6sh6ic$o8p$1@nnrp1.dejanews.com>... >> >Making the code as simple as possible in order to solve the problem at hand >> >is more important than trying to make it easier to change against some >> >imaginary future changes. >> >> I disagree one last time. Two digit dates are much easier to deal with than >> four digit dates. Until the century changes... > >INMO, 2 digit dates were >an engineering tradeoff, that made sense when they were written >just like 4 digit dates do now (which will break after the year 9999). If only it were so. But of course many of the Y2K problems are not being solved by expanding the field to four digits. Rather they are adding *code* not *space*. The technique is called windowing. Whenver date subtractions or comparisons are done in the code, they interpreted as follows: if date > X assume 1900 else assume 2000 If X is 50 then any date larger than 50 is assumed to be in the 20th century. Otherwise the data is assumed to be in the 21st century. This, of course, means that there will be a Y2050 crisis. Ah, but no. Because X is not universally agreed upon. Some applications use 60, some use 40. So what we really have is a smearing of the crisis over the next several decades. Of course none of those old COBOL programs will still be running then... The choice to use windowing rather than 4 digit dates is also an engineering trade off. >> The engineer who does not >> design for maintainability, is doing a disservice to himself, his fellow >> engineers, and his employer. > >More bs. The argument is if using flags to conform to the se/se principle, >makes the code more maintainable. >The engineer who spends his time making his code more complex to protect >against a certain kind of changes (which are better handled using techniques, >such as Resource acquisition is initialization) is wasting the time of his >fellow engineers and the resources of his employer. Granted. Now, what takes longer. Creating new classes and managing resources in their constructors and destructors; or maintaining single-entry/single-exit style? RAI is a very nice technique, and I am happy to use it for certain kinds of exception protection. Expecially when the classes have already been built (e.g. auto_ptr). On the other hand, there are resources that don't lend well to management from destructors. And for those, I prefer to use se/se as an aid to their management. In the final analysis, we are not talking about a huge investment. se/se functions are not horribly more complex, or terribly difficult to read. They are software, like any other. Their structure is more conducive to certain kinds of maintenance. The cost of building se/se is reasonably low. These are data points for making engineering trade offs. If you have a function that can be managed with RAI, and you are reasonably sure that this will be the case for the forseeable future, and you really need a few extra minutes, then by all means use multiple exits. On the other hand, if you think its possible that RAI will be insufficient to handle the resource needs of your functions in the forseeable future, and you can spare a few extra minutes to work out the se/se structure, you are probably better off doing so. 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