Re: Software landmines (loops)

[Mike Spille <mspille@tisny.com>]

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