Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #20657 > unrolled thread

Redundant return()

Back to article view | Back to comp.lang.c

Contents

  Redundant return() pembed2012 <once@was.enough.invalid> - 2012-05-12 21:41 +0000
    Re: Redundant return() pembed2012 <once@was.enough.invalid> - 2012-05-12 21:56 +0000
      Re: Redundant return() Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-05-12 17:07 -0600
    Re: Redundant return() James Kuyper <jameskuyper@verizon.net> - 2012-05-12 18:46 -0400
      Re: Redundant return() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-12 20:10 -0400
        Re: Redundant return() James Kuyper <jameskuyper@verizon.net> - 2012-05-12 21:29 -0400
    Re: Redundant return() Barry Schwarz <schwarzb@dqel.com> - 2012-05-12 15:49 -0700
      Re: Redundant return() pembed2012 <once@was.enough.invalid> - 2012-05-14 16:40 +0000
        Re: Redundant return() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-14 17:57 +0100
        Re: Redundant return() nick_keighley_nospam@hotmail.com - 2012-05-15 00:33 -0700
          Re: Redundant return() nick_keighley_nospam@hotmail.com - 2012-05-15 03:03 -0700
            Re: Redundant return() nick_keighley_nospam@hotmail.com - 2012-05-15 03:26 -0700
            Re: Redundant return() James Kuyper <jameskuyper@verizon.net> - 2012-05-15 08:51 -0400
          Re: Redundant return() "BartC" <bc@freeuk.com> - 2012-05-15 12:20 +0100
            Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 07:59 +1200
              Re: Redundant return() Kaz Kylheku <kaz@kylheku.com> - 2012-05-15 20:08 +0000
                Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 08:18 +1200
                  Re: Redundant return() Lanarcam <lanarcam1@yahoo.fr> - 2012-05-15 22:48 +0200
                    Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 09:56 +1200
              Re: Redundant return() "BartC" <bc@freeuk.com> - 2012-05-15 22:59 +0100
                Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 10:16 +1200
                  Re: Redundant return() "BartC" <bc@freeuk.com> - 2012-05-16 09:29 +0100
          Re: Redundant return() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-15 07:51 -0400
          Re: Redundant return() James Kuyper <jameskuyper@verizon.net> - 2012-05-15 08:47 -0400
            Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 08:01 +1200
            Re: Redundant return() "BartC" <bc@freeuk.com> - 2012-05-15 22:58 +0100
              Re: Redundant return() Ian Collins <ian-news@hotmail.com> - 2012-05-16 10:24 +1200
                Re: Redundant return() James Kuyper <jameskuyper@verizon.net> - 2012-05-15 18:39 -0400
                Re: Redundant return() nick_keighley_nospam@hotmail.com - 2012-05-16 02:45 -0700
    Re: Redundant return() Noob <root@127.0.0.1> - 2012-05-16 13:34 +0200

Page 1 of 2  [1] 2  Next page →

#20657 — Redundant return()

I have seen redundant return statements at the end of function. IE.
        init_function()
        {
                a_init();
                b_init();
                c_init();
                return();
        }
I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
is ignored so it not harmful to use this.

Has anybody got any problem/issues with this on any compiler/platform?

[toc] | [next] | [standalone]

#20659

sorry function shall be a VOID function :-)

On Sat, 12 May 2012 21:41:12 +0000, pembed2012 wrote:
> I have seen redundant return statements at the end of function. IE.
>         init_function()
>         {
>                 a_init();
>                 b_init();
>                 c_init();
>                 return();
>         }
> I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
> is ignored so it not harmful to use this.
> 
> Has anybody got any problem/issues with this on any compiler/platform?

[toc] | [prev] | [next] | [standalone]

#20663

pembed2012 <once@was.enough.invalid> writes:

> sorry function shall be a VOID function :-)
>
> On Sat, 12 May 2012 21:41:12 +0000, pembed2012 wrote:
>> I have seen redundant return statements at the end of function. IE.
>>         init_function()
>>         {
>>                 a_init();
>>                 b_init();
>>                 c_init();
>>                 return();
>>         }
>> I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
>> is ignored so it not harmful to use this.
>> 
>> Has anybody got any problem/issues with this on any compiler/platform?

Well...  no problem with the explicit return (I'm pretty sloppy about
whether I use them or not), but there is a problem with your example
(just to be sure, I checked and here's what gcc told me):

bogus.c:13:12: error: expected expression before ‘)’ token
bogus.c:13:5: warning: ‘return’ with a value, in function returning void [enabled by default]

[toc] | [prev] | [next] | [standalone]

#20661

On 05/12/2012 05:41 PM, pembed2012 wrote:
> I have seen redundant return statements at the end of function. IE.
>         init_function()
>         {
>                 a_init();
>                 b_init();
>                 c_init();
>                 return();
>         }
> I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
> is ignored so it not harmful to use this.
> 
> Has anybody got any problem/issues with this on any compiler/platform?

I wouldn't use a "return;" where it wasn't needed, for the same reason I
wouldn't use parentheses in a place where they aren't needed, such as
"return();". However, they should never cause any actual problems.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#20666

On 5/12/2012 6:46 PM, James Kuyper wrote:
> On 05/12/2012 05:41 PM, pembed2012 wrote:
>> I have seen redundant return statements at the end of function. IE.
>>          init_function()
>>          {
>>                  a_init();
>>                  b_init();
>>                  c_init();
>>                  return();
>>          }
>> I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
>> is ignored so it not harmful to use this.
>>
>> Has anybody got any problem/issues with this on any compiler/platform?
>
> I wouldn't use a "return;" where it wasn't needed, for the same reason I
> wouldn't use parentheses in a place where they aren't needed, such as
> "return();". However, they should never cause any actual problems.

     Section 6.4.1 lists `return' as a keyword, so it cannot be
an identifier.  Nor, by omission from other sections, can it be
an operator.  6.8.6 describes the only valid context for the
keyword, giving it as (ASCII adaptation)

	return  expression[opt]  ;

Since `()' matches neither `expression' nor `absence of expression',
it follows that `return();' is a syntax error requiring a diagnostic.

     ... but other than that, Mrs. Lincoln, there are no actual
problems.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#20667

On 05/12/2012 08:10 PM, Eric Sosman wrote:
> On 5/12/2012 6:46 PM, James Kuyper wrote:
>> On 05/12/2012 05:41 PM, pembed2012 wrote:
>>> I have seen redundant return statements at the end of function. IE.
>>>          init_function()
>>>          {
>>>                  a_init();
>>>                  b_init();
>>>                  c_init();
>>>                  return();
>>>          }
>>> I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
>>> is ignored so it not harmful to use this.
>>>
>>> Has anybody got any problem/issues with this on any compiler/platform?
>>
>> I wouldn't use a "return;" where it wasn't needed, for the same reason I
>> wouldn't use parentheses in a place where they aren't needed, such as
>> "return();". However, they should never cause any actual problems.
> 
>      Section 6.4.1 lists `return' as a keyword, so it cannot be
> an identifier.  Nor, by omission from other sections, can it be
> an operator.  6.8.6 describes the only valid context for the
> keyword, giving it as (ASCII adaptation)
> 
> 	return  expression[opt]  ;
> 
> Since `()' matches neither `expression' nor `absence of expression',
> it follows that `return();' is a syntax error requiring a diagnostic.

You're right, I missed that. His question focused me on the redundancy
of the return statement, rather than whether it was syntactically correct.
-
James Kuyper

[toc] | [prev] | [next] | [standalone]

#20662

On Sat, 12 May 2012 21:41:12 +0000 (UTC), pembed2012
<once@was.enough.invalid> wrote:

>I have seen redundant return statements at the end of function. IE.
>        init_function()
>        {
>                a_init();
>                b_init();
>                c_init();
>                return();

ITYM return;

>        }
>I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
>is ignored so it not harmful to use this.
>
>Has anybody got any problem/issues with this on any compiler/platform?

Some organizations have coding standards which require each function
to have exactly one explicit return at the end of the function.  It
simplifies maintenance if the type or presence of a return value needs
to be changed during a software update.

I wonder what kind of problem you envision.  At worst, a brain dead
compiler could generate instructions for the return statement and then
a second set of (duplicate?) instructions for the implied return at
the closing brace.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#20703

On Sat, 12 May 2012 15:49:57 -0700, Barry Schwarz wrote:

> On Sat, 12 May 2012 21:41:12 +0000 (UTC), pembed2012
> <once@was.enough.invalid> wrote:
> 
>>I have seen redundant return statements at the end of function. IE.
>>        init_function()
>>        {
>>                a_init();
>>                b_init();
>>                c_init();
>>                return();
> 
> ITYM return;
> 
>>        }
>>I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
>>is ignored so it not harmful to use this.
>>
>>Has anybody got any problem/issues with this on any compiler/platform?
> 
> Some organizations have coding standards which require each function to
> have exactly one explicit return at the end of the function.  It
> simplifies maintenance if the type or presence of a return value needs
> to be changed during a software update.
> 
> I wonder what kind of problem you envision.  At worst, a brain dead
> compiler could generate instructions for the return statement and then a
> second set of (duplicate?) instructions for the implied return at the
> closing brace.

Ho, you are right, I can invoke the return function with no () and there 
is no compiler error. Wired.

I thought in a VOID function it will be an error to invoke return, maybe 
clobber the place in the stack that would store a return val in a non-
VOID function etc.

[toc] | [prev] | [next] | [standalone]

#20706

pembed2012 <once@was.enough.invalid> writes:

> On Sat, 12 May 2012 15:49:57 -0700, Barry Schwarz wrote:
>
>> On Sat, 12 May 2012 21:41:12 +0000 (UTC), pembed2012
>> <once@was.enough.invalid> wrote:
>> 
>>>I have seen redundant return statements at the end of function. IE.
>>>        init_function()
>>>        {
>>>                a_init();
>>>                b_init();
>>>                c_init();
>>>                return();
>> 
>> ITYM return;
>> 
>>>        }
>>>I checked the generated code in GCC Compiler 3.2.2 on Red Hat Linux it
>>>is ignored so it not harmful to use this.
>>>
>>>Has anybody got any problem/issues with this on any compiler/platform?
>> 
>> Some organizations have coding standards which require each function to
>> have exactly one explicit return at the end of the function.  It
>> simplifies maintenance if the type or presence of a return value needs
>> to be changed during a software update.
>> 
>> I wonder what kind of problem you envision.  At worst, a brain dead
>> compiler could generate instructions for the return statement and then a
>> second set of (duplicate?) instructions for the implied return at the
>> closing brace.
>
> Ho, you are right, I can invoke the return function with no () and there 
> is no compiler error. Wired.

It's not a function -- it's a statement, and using empty brackets is
*always* wrong.  What's more you don't need the brackets even when there
is an expression.  Both

  return;

and

  return 42;

are valid, though it's a mistake to use the first form in a function
that has non-void return type or to use the second form in a function
that is declared "void".

> I thought in a VOID function it will be an error to invoke return, maybe 
> clobber the place in the stack that would store a return val in a non-
> VOID function etc.

No, it's fine.  You can have any number of return statement in a "void"
function -- provided you don't try to return a value.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#20788

On Monday, May 14, 2012 5:40:34 PM UTC+1, pembed2012 wrote:

<snip>

> Ho, you are right, I can invoke the return function with no () and there 
> is no compiler error. Wired.

as others have pointed out "return IS NOT a function!"

> I thought in a VOID function it will be an error to invoke return, maybe 
> clobber the place in the stack that would store a return val in a non-
> VOID function etc.

some odd misconceptions. An early return can be handy. Though som people (not me) dislike it for reasons of style

void writeLog (FILE *log, const char *msg)
{
    if (log == NULL)
        return;

    /* complex processing */
    fprintf (log, "LOG: %s %s\n", timestamp(), msg);
}

[toc] | [prev] | [next] | [standalone]

#20793

On Tuesday, May 15, 2012 8:51:40 AM UTC+1, Stefan Ram wrote:
> >On Monday, May 14, 2012 5:40:34 PM UTC+1, pembed2012 wrote:

> >>Ho, you are right, I can invoke the return function with no () and there 
> >>is no compiler error. Wired.
>
>   The supposed spelling is »wierd«.

"supposed spelling"? Not "correct spelling"?

I must admit i just assumed he was on drugs.  :-)

> nick_keighley writes:
> >some odd misconceptions. An early return can be handy.
> 
>   »handy« is vague wording.

yes it is. That's why I gave an example of an early return.

> >if (log == NULL)
> >    return;
> >/* complex processing */
> 
>   If it is complex, we put it into a function »f«, so:
> 
> if( log ){ f(); fprintf( log, "LOG: %s\n", msg ); }

why? My code was clear and easy to understand. This is just single-exit bigotry.

>   . The real reason for an early return as in

"real"? Why is this any more "real" than any other reason? What you meant to say is "another reason"

> while( ... )
> { ...
>   if( ... )return result;
>   ... }
> 
>   is that tests have shown that this often executes faster
>   than a single exit.

"often"? On all architectures? At all optimisation  levels? How much faster? this is micro-optimisation (at best); something we normal discourage newbies from indulging in.

I submit my usage of early return, to detect special cases early on and avoid deep nesting, is more "real" than your obscure micro-optimisation trick.

[toc] | [prev] | [next] | [standalone]

#20796

On Tuesday, May 15, 2012 11:21:19 AM UTC+1, Stefan Ram wrote:
> nick_keighley_nospam@hotmail.com writes:
> >On Tuesday, May 15, 2012 8:51:40 AM UTC+1, Stefan Ram wrote:
> >>nick_keighley writes:

like I said in a bit of my post you snipped. This is a style thing. Some people like to jump through hoops to give single-entry-single-exit properties to their code. Some don't. I simply object to you stating it as if it were some sort of Programming Law.

> >>>/* complex processing */
> >why? My code was clear and easy to understand.
> 
>   Assume, you had complex code:
> 
>   ...
>     ... return ...
>       ... 
>     ... return ...
>       ... return ...
>     ...
>   ...
>     ... return ...
>       ...
>     ... return ...
>       ... return ...
>     ...

I don't usually write code that is as complicated as that.

>   The many returns hinder extract-function refactoring,

haven't noticed a problem.

>   because, when you want to extract the first half of this
>   into a separate function, the returns now jump to the end of
>   that new function, which usually is not what they are
>   supposed to do, so one has to do a more complex and
>   error-prone rewriting during this refactor.
> 
>   When a block has a single entry and exit, the 
>   extract-function refactor is usually easy.
> 
>   This could be a reason that complex code such as 
>   above is not refactored, so that it will be harder
>   to maintain.
> 
> >>. The real reason for an early return as in
> >"real"? Why is this any more "real" than any other reason?
> 
>   It is the only excuse that I accept for the use of multiple
>   returns in a function.

whatever

[toc] | [prev] | [next] | [standalone]

#20803

On 05/15/2012 06:21 AM, Stefan Ram wrote:
> nick_keighley_nospam@hotmail.com writes:
>> On Tuesday, May 15, 2012 8:51:40 AM UTC+1, Stefan Ram wrote:
>>> nick_keighley writes:
>>>> /* complex processing */
>> why? My code was clear and easy to understand.
> 
>   Assume, you had complex code:
> 
>   ...
>     ... return ...
>       ... 
>     ... return ...
>       ... return ...
>     ...
>   ...
>     ... return ...
>       ...
>     ... return ...
>       ... return ...
>     ...
> 
>   The many returns hinder extract-function refactoring,
>   because, when you want to extract the first half of this
>   into a separate function, the returns now jump to the end of
>   that new function, which usually is not what they are
>   supposed to do, so one has to do a more complex and
>   error-prone rewriting during this refactor.
> 
>   When a block has a single entry and exit, the 
>   extract-function refactor is usually easy.

In my personal experience, early returns usually correspond to error
conditions, so jumping to the end of the new function is usually what I
want them to do.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#20798

"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:return-20120515095002@ram.dialup.fu-berlin.de...
>>On Monday, May 14, 2012 5:40:34 PM UTC+1, pembed2012 wrote:
>>>Ho, you are right, I can invoke the return function with no () and there
>>>is no compiler error. Wired.
>
>  The supposed spelling is »wierd«.
>
> nick_keighley_nospam@hotmail.com writes:
>>some odd misconceptions. An early return can be handy.
>
>  »handy« is vague wording.
>
>>if (log == NULL)
>>    return;
>>/* complex processing */
>
>  If it is complex, we put it into a function »f«, so:
>
> if( log ){ f(); fprintf( log, "LOG: %s\n", msg ); }

This is crazy. The effect is to create an extra function (the current one)
which contains just a single statement, more or less.

If the return was half-way through the function, you'd then be splitting it
into two for probably no reason, and would have the headache of making all
the locals which have been used and set up, available to the new function.

>  If it is complex, we put it into a function »f«, so:

But the body of f() will still be complex (as you've only eliminated a
couple of lines; it that now makes it simple, then it was *not* complex!);
then what? Suppose there were several such returns in a function? You would
end up *increasing* complexity (by extra functions, extra names, extra
interfaces) for no discernible benefit. Actually it would be probably be
slower, less readable, and more buggy.

-- 
Bartc
 

[toc] | [prev] | [next] | [standalone]

#20817

On 05/15/12 11:20 PM, BartC wrote:
> "Stefan Ram"<ram@zedat.fu-berlin.de>  wrote:
>
>>   If it is complex, we put it into a function »f«, so:
>
> But the body of f() will still be complex (as you've only eliminated a
> couple of lines; it that now makes it simple, then it was *not* complex!);
> then what? Suppose there were several such returns in a function? You would
> end up *increasing* complexity (by extra functions, extra names, extra
> interfaces) for no discernible benefit. Actually it would be probably be
> slower, less readable, and more buggy.

Testing.  A large, complex, function is hard to test.  More less complex 
functions are easier to test.  That's why code written test first won't 
contain large, complex, functions.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#20819

On 2012-05-15, Ian Collins <ian-news@hotmail.com> wrote:
> On 05/15/12 11:20 PM, BartC wrote:
>> "Stefan Ram"<ram@zedat.fu-berlin.de>  wrote:
>>
>>>   If it is complex, we put it into a function »f«, so:
>>
>> But the body of f() will still be complex (as you've only eliminated a
>> couple of lines; it that now makes it simple, then it was *not* complex!);
>> then what? Suppose there were several such returns in a function? You would
>> end up *increasing* complexity (by extra functions, extra names, extra
>> interfaces) for no discernible benefit. Actually it would be probably be
>> slower, less readable, and more buggy.
>
> Testing.  A large, complex, function is hard to test.  More less complex 
> functions are easier to test.  That's why code written test first won't 
> contain large, complex, functions.

Sure it will.  Start with a small well-tested function, and grow it, carefully
testing every increment. You end up with a big function that is supported
by a large number of tests.

-- 
If you ever need any coding done, I'm your goto man!

[toc] | [prev] | [next] | [standalone]

#20822

On 05/16/12 08:08 AM, Kaz Kylheku wrote:
> On 2012-05-15, Ian Collins<ian-news@hotmail.com>  wrote:
>> On 05/15/12 11:20 PM, BartC wrote:
>>> "Stefan Ram"<ram@zedat.fu-berlin.de>   wrote:
>>>
>>>>    If it is complex, we put it into a function »f«, so:
>>>
>>> But the body of f() will still be complex (as you've only eliminated a
>>> couple of lines; it that now makes it simple, then it was *not* complex!);
>>> then what? Suppose there were several such returns in a function? You would
>>> end up *increasing* complexity (by extra functions, extra names, extra
>>> interfaces) for no discernible benefit. Actually it would be probably be
>>> slower, less readable, and more buggy.
>>
>> Testing.  A large, complex, function is hard to test.  More less complex
>> functions are easier to test.  That's why code written test first won't
>> contain large, complex, functions.
>
> Sure it will.  Start with a small well-tested function, and grow it, carefully
> testing every increment. You end up with a big function that is supported
> by a large number of tests.

That only happens if you don't refactor as you go.  Even if it is well 
tested, a big function is still a fragile thing.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#20825

Le 15/05/2012 22:18, Ian Collins a écrit :
> On 05/16/12 08:08 AM, Kaz Kylheku wrote:
>> On 2012-05-15, Ian Collins<ian-news@hotmail.com> wrote:
>>> On 05/15/12 11:20 PM, BartC wrote:
>>>> "Stefan Ram"<ram@zedat.fu-berlin.de> wrote:
>>>>
>>>>> If it is complex, we put it into a function »f«, so:
>>>>
>>>> But the body of f() will still be complex (as you've only eliminated a
>>>> couple of lines; it that now makes it simple, then it was *not*
>>>> complex!);
>>>> then what? Suppose there were several such returns in a function?
>>>> You would
>>>> end up *increasing* complexity (by extra functions, extra names, extra
>>>> interfaces) for no discernible benefit. Actually it would be
>>>> probably be
>>>> slower, less readable, and more buggy.
>>>
>>> Testing. A large, complex, function is hard to test. More less complex
>>> functions are easier to test. That's why code written test first won't
>>> contain large, complex, functions.
>>
>> Sure it will. Start with a small well-tested function, and grow it,
>> carefully
>> testing every increment. You end up with a big function that is supported
>> by a large number of tests.
>
> That only happens if you don't refactor as you go. Even if it is well
> tested, a big function is still a fragile thing.
>
IMO, a function, for reasons of maintenance, must be short,
two pages max, and easily understandable. Large chunks of code
should be replaced with calls to functions with meaningful names
and few parameters. It should be easy to understand it at the
first reading without being lost in obscure details and forgetting
the logic of the whole.

[toc] | [prev] | [next] | [standalone]

#20829

On 05/16/12 08:48 AM, Lanarcam wrote:
> Le 15/05/2012 22:18, Ian Collins a écrit :
>> On 05/16/12 08:08 AM, Kaz Kylheku wrote:
>>> On 2012-05-15, Ian Collins<ian-news@hotmail.com>  wrote:
>>>> On 05/15/12 11:20 PM, BartC wrote:
>>>>> "Stefan Ram"<ram@zedat.fu-berlin.de>  wrote:
>>>>>
>>>>>> If it is complex, we put it into a function »f«, so:
>>>>>
>>>>> But the body of f() will still be complex (as you've only eliminated a
>>>>> couple of lines; it that now makes it simple, then it was *not*
>>>>> complex!);
>>>>> then what? Suppose there were several such returns in a function?
>>>>> You would
>>>>> end up *increasing* complexity (by extra functions, extra names, extra
>>>>> interfaces) for no discernible benefit. Actually it would be
>>>>> probably be
>>>>> slower, less readable, and more buggy.
>>>>
>>>> Testing. A large, complex, function is hard to test. More less complex
>>>> functions are easier to test. That's why code written test first won't
>>>> contain large, complex, functions.
>>>
>>> Sure it will. Start with a small well-tested function, and grow it,
>>> carefully
>>> testing every increment. You end up with a big function that is supported
>>> by a large number of tests.
>>
>> That only happens if you don't refactor as you go. Even if it is well
>> tested, a big function is still a fragile thing.
>>
> IMO, a function, for reasons of maintenance, must be short,
> two pages max, and easily understandable. Large chunks of code
> should be replaced with calls to functions with meaningful names
> and few parameters. It should be easy to understand it at the
> first reading without being lost in obscure details and forgetting
> the logic of the whole.

Two *pages*? blimey.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#20831

"Ian Collins" <ian-news@hotmail.com> wrote in message
news:a1fqsoFd96U1@mid.individual.net...
> On 05/15/12 11:20 PM, BartC wrote:
>> "Stefan Ram"<ram@zedat.fu-berlin.de>  wrote:
>>
>>>   If it is complex, we put it into a function »f«, so:
>>
>> But the body of f() will still be complex (as you've only eliminated a
>> couple of lines; it that now makes it simple, then it was *not*
>> complex!);
>> then what? Suppose there were several such returns in a function? You
>> would
>> end up *increasing* complexity (by extra functions, extra names, extra
>> interfaces) for no discernible benefit. Actually it would be probably be
>> slower, less readable, and more buggy.
>
> Testing.  A large, complex, function is hard to test.  More less complex
> functions are easier to test.

I don't see that. You're testing inputs and outputs. A function which is
'complex' in the amount of logic it contains, can still have simple
requirements and be straightforward to test.

But one which is arbitrarily broken up into pieces, now needs to have a
meaningful set of specifications drawn up for each part.

> That's why code written test first won't contain large, complex,
> functions.

That's right; you build a framework of one hundred functions, all initially
empty (or with some stub). They each do ten different things depending on
some parameter. Each of those things is straightforward by itself, but can
be added one by one, function by function. In the end you have 5000
different things split amongst 100 functions.

Your way, there would be 5000 2-line functions. Plus 100 dispatcher
functions. And most of the relationships amongst each group of ten, has 
disappeared.

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web