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/08 Message-ID: <35F563D7.C3CA7146@tisny.com>#1/1 X-Deja-AN: 389176095 Content-Transfer-Encoding: 7bit References: <6t0q1h$m5b$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-08T00:00:00+00:00 List-Id: Robert Martin wrote: > > Mike Spille wrote in message <35F0484A.2108A9F@tisny.com>... > >Robert Martin wrote: > >> > >> > >> int f(char* name) // returns status value > >> { > >> int status = 0; > >> if (File* f = fopen(name, "r")) > >> { > >> if (char* buffer = malloc(80)) > >> { > >> DoSomethingUseful(f,buffer); > >> free(buffer); > >> } > >> else // malloc failure > >> { > >> Log("malloc failure"); > >> status = -2; > >> } > >> fclose(f); > >> } > >> else // fopen failure > >> { > >> Log("Failure to fopen"); > >> status = -1; > >> } > >> return status; > >> } > >> > >> Perhaps you think this is cumbersome. I don't. Cumbersome is a rather > >> subjective term. > >> > > > >I find it quite cumbersome, and error prone to boot. I'd do it as: > > > >int f(char* name) // returns status value > >{ > > char buf[80]; > > FILE* f = fopen(name, "r"); > > if (f == NULL) { > > Log("Failure to fopen"); > > return (-1); > > } > > > > DoSomethingUseful(f,buf, sizeof(buf)); > > fclose (f); > >} > > > >That is, use a stack-based buffer and pass in the size of the char array to > >do something useful so it doesn't walk off the end of the buffer by mistake > >(assuming that DoSomethingUseful is smart enough to include a size > argument). > > Come one Mike, I was using the program as an example. It's not a real > program. If you like I'll add the requirement that the buffer *must* come > from the heap because stack and heap memory run at different speeds, and the > 'DoSomethingUseful' function needs the heap speed memory. (Sounds crazy but > one of my clients has a platform with just such a constraint). As for > passing in the size, you have a point -- but its completely irrelevant to > the topic at hand. In short, you are clutching at straws. > No, I was pointing out that you lost for the forest for the trees. While pointing out the possible advantages of single entry/return, you meanwhile ignored common C/C++ coding practices: keep functions as small as possible, don't malloc() unnecessarily, always pass array sizes around with arrays. By concentrating on the advantages of your particular style, you managed to write a rather poor function. > >My point? I focused on what the routine was supposed to do, not on a > >methodology, > > And apparently not on what we were discussing. We were not discussing > whether buffers should be stack or heap based. We were not discussing > whether size variables should be passed along with buffers. We were > discussing whether or not se/se makes a function cumbersome. I used an > example to make a point, and you side stepped the point. > Once upon a time a buddy of mine was writing a C coding guidelines manual for a company we both worked for. He asked me to proof read it for him. I did so, and while I had some mild objections here and there I found his guidelines reasonable - with one exception. At the end of the guide he provided an example that demonstrated some of the major style-points he had touched upon. His example did indeed avoid all the downfalls he had warned against in his writing, and followed the style he'd outlined perfectly. Unfortunately, the algorithm he had coded was horrendously inefficient, and buggy to boot. In his zeal to promote his guidelines, he'd forgotten to focus on what the algorithm was supposed to do. I would say that you did the same - you focused so much on the style of the code that you ignored the algorithm. The end-goal of writing a function is primarily that it does what you want it to do, and does it well. If you focus more on following a given set of rules than you do on what you're trying to accomplish, your results are going to reflect your priorities. > >(And I think it's more readable :-) > > Which makes my point about subjectivity for me. > > -- > > 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