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

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

Is goto Still Considered Harmful?

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

Contents

  Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-12 11:02 -0500
    Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 12:17 -0400
    Re: Is goto Still Considered Harmful? nospam@see.signature (Richard Maine) - 2014-03-12 09:20 -0700
      Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-18 16:30 -0500
        Re: Is goto Still Considered Harmful? Geoff <geoff@invalid.invalid> - 2014-03-18 17:36 -0700
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-19 07:34 -0400
            Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-19 12:08 +0000
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-19 10:07 -0400
                Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-19 17:05 +0100
              Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-19 12:27 -0500
        Re: Is goto Still Considered Harmful? "Terence" <tbwright@bigpond.net.au> - 2014-03-19 20:35 +1100
          Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-19 12:26 -0500
    Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 16:47 +0000
      Re: Is goto Still Considered Harmful? Jos Bergervoet <jos.bergervoet@xs4all.nl> - 2014-03-12 19:07 +0100
        Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-12 23:36 +0000
          Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 00:23 +0000
            Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-13 01:18 +0000
              Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 02:08 +0000
                Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-13 02:21 +0000
                Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:17 +0100
          Re: Is goto Still Considered Harmful? Melzzzzz <mel@zzzzz.invalid> - 2014-03-13 01:53 +0100
        Re: Is goto Still Considered Harmful? Les Cargill <lcargill99@comcast.com> - 2014-03-13 01:46 -0500
      Re: Is goto Still Considered Harmful? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-13 10:56 +0100
      Re: Is goto Still Considered Harmful? "Nasser M. Abbasi" <nma@12000.org> - 2014-03-16 08:18 -0500
        Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-16 15:18 +0000
          Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-20 11:36 -0700
    Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-12 18:50 +0000
      Re: Is goto Still Considered Harmful? <william@wilbur.25thandClement.com> - 2014-03-12 12:49 -0700
      Re: Is goto Still Considered Harmful? "Qolin" <noone@nowhere.com> - 2014-03-12 21:54 +0000
        Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-12 16:57 -0500
        Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 15:36 -0700
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 19:02 -0400
            Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 16:58 -0700
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 20:09 -0400
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 16:44 -0700
        Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-12 23:40 -0500
          Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:25 +0100
          Re: Is goto Still Considered Harmful? Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-03-14 11:24 +0100
            Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-14 23:32 -0500
            Re: Is goto Still Considered Harmful? Dr Nick <nospam-4@temporary-address.org.uk> - 2014-03-15 13:43 +0000
              Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-15 16:28 +0100
                Re: Is goto Still Considered Harmful? Dr Nick <nospam-4@temporary-address.org.uk> - 2014-03-15 16:01 +0000
                  Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-17 08:51 +0100
      Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:22 +0100
    Re: Is goto Still Considered Harmful? ralph <nt_consulting@yahoo.com> - 2014-03-12 15:34 -0500
    Re: Is goto Still Considered Harmful? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-03-12 17:48 -0700
    Re: Is goto Still Considered Harmful? jt@toerring.de (Jens Thoms Toerring) - 2014-03-13 01:06 +0000
      Re: Is goto Still Considered Harmful? wilson <winslole@udayton.edu> - 2014-03-13 03:59 -0400
        Re: Is goto Still Considered Harmful? wilson <winslole@udayton.edu> - 2014-03-13 05:02 -0400
          Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-03-13 08:42 -0400
            Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-13 14:45 +0000
      Re: Is goto Still Considered Harmful? Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2014-03-13 07:42 -0600
        Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-13 14:56 +0100
    Re: Is goto Still Considered Harmful? Wolfgang Kilian <kilian@invalid.com> - 2014-03-13 09:10 +0100
    Re: Is goto Still Considered Harmful? mark.bluemel@gmail.com - 2014-03-13 08:02 -0700
    Re: Is goto Still Considered Harmful? Thomas Koenig <tkoenig@netcologne.de> - 2014-03-13 21:09 +0000
      Re: Is goto Still Considered Harmful? "Qolin" <noone@nowhere.com> - 2014-03-13 21:24 +0000
        Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-13 22:36 +0000
          Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:02 -0500
            Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 04:07 +0000
              Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:56 -0500
            Re: Is goto Still Considered Harmful? helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) - 2014-03-14 09:17 +0000
      Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 22:42 +0000
        Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-13 17:13 -0600
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-13 16:46 -0700
            Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 01:17 +0000
              Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:04 -0500
                Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-14 10:41 +0100
                  Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 09:55 +0000
                    Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-14 13:16 +0100
                    Re: Is goto Still Considered Harmful? Seebs <usenet-nospam@seebs.net> - 2014-03-18 21:08 +0000
                      Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-18 17:41 -0400
          Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 00:45 +0000
            Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-13 21:40 -0600
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 01:02 -0400
                Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-14 10:36 -0600
                  Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-14 17:30 +0000
                  Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 13:51 -0400
                    Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-14 13:12 -0700
                  Re: Is goto Still Considered Harmful? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 06:46 -0700
              Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 05:29 +0000
                Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-14 10:47 -0600
                  Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-14 17:43 +0000
                  Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 13:52 -0400
              Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-16 17:15 -0500
                Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-16 16:04 -0700
      Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 05:11 +0000
        Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 06:00 +0000
    Re: Is goto Still Considered Harmful? "Terence" <tbwright@bigpond.net.au> - 2014-03-14 08:32 +1100
      Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-03-14 23:10 -0400
    Re: Is goto Still Considered Harmful? Rosario193 <Rosario@invalid.invalid> - 2014-03-14 02:18 +0100
      Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-18 16:14 -0500
    Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 07:52 -0700
      Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-24 11:20 -0400
        Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-24 17:08 +0000
        Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-25 14:06 -0400
          Re: Is goto Still Considered Harmful? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-03-26 13:31 -0400
      Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-24 16:31 +0000
      Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-24 16:46 +0000
        Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 16:10 -0700
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-24 17:19 -0700
            Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-25 02:56 -0700
            Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-25 07:34 -0700
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-25 10:57 -0400
                Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-25 16:09 +0000
                Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-25 16:14 +0000
                  Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-03-26 08:06 +1300
                  Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-25 12:49 -0700
                  Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 14:05 -0500
                    Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 15:20 -0400
                      Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-04-04 14:56 -0500
                        Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-04-04 17:11 -0400
                          Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-05 12:03 +1300
                          Re: Is goto Still Considered Harmful? ralph <nt_consulting@yahoo.com> - 2014-04-05 00:17 -0500
                            Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-05 20:14 +1300
                          Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-04-09 14:30 -0500
                            Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-04-09 16:37 -0400
                              Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-09 14:01 -0700
                        Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-04-05 15:21 +0100
                    Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-01 11:04 +1300
                      Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-04-01 02:45 +0300
                        Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-01 13:03 +1300
                          Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-05-22 12:01 +0300
                            Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-05-22 21:22 +1200
                        Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-05-22 11:53 +0300
                Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 12:10 -0400
                  Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-31 10:39 -0700
                    Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 13:42 -0500
                      Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-31 15:16 -0700
                        Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-01 00:24 -0700
                          Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-04-01 08:26 -0400
                            Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-01 06:50 -0700
                              Re: Are setters Stil Considered Harmful? (was: Is goto Still Considered Harmful?) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-02 10:49 -0700
              Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-25 19:30 +0000
                Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-27 09:33 -0400
              Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-25 19:37 +0000
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-25 00:30 -0400
          Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-27 11:47 -0700
            Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-27 20:39 -0400
              Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-28 01:40 +0000
            Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-28 10:09 +0100
              Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-28 09:48 +0000
              Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-28 03:24 -0700
                Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-28 18:52 +0000
                Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-30 02:45 -0700
      Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-24 12:53 -0700
      Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 15:02 -0700
        Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-24 19:11 -0400
    Re: Is goto Still Considered Harmful? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 05:56 -0700

Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8  Next page →

#42118

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> John Bode <jfbode1029@gmail.com> writes:
>>Is that example completely contrived?  I wish I could say it was.  It was 
>>inspired by real code I've had to review in the past (except that "foo" was
>>several *thousand* lines long and there were 12 or 13 more labels with
>>gotos branching all over the goddamned place).  
>
>   As others and I have said before: One might as well claim that in this
>   case, the problem is not the use of gotos, but the huge size of functions.
>
>   This is comp.lang.c; so, when someone asks about »goto«, we assume he
>   refers to »goto in C«. In C, we (except beginners) write short functions.

I'm not aware of any particular connection between writing short
functions and the C langauge.

To put it another way, if we assume that writing short functions is A
Good Thing, I don't see how it's any more (or less) of a good thing in C
than in any other language.

Are there languages in which long functions are acceptable in your
opinion?

>   Of course, who here would deny that refactoring a huge old-style 
>   monolithic program into a modern procedural and structured program is 
>   a lot of (possibly unpleasant and difficult) work? But when one is doing
>   it for an appropriate pay, it might be fair.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#42130

On Tuesday, March 25, 2014 12:19:29 AM UTC, Keith Thompson wrote:
> 
> I'm not aware of any particular connection between writing short
> functions and the C langauge.
> 
In C, a function call is cheap. Then in decent C, you have to declare variables
in block scope, which means that if the function gets long, the local variable
list gets long, which acts as a kind of psychological warning that the function
is getting out of control. (A lot of people also use the convention that
variables must always be declared in function scope).
Then trivial standard library operations like strcpy() are also implemented 
as functions, which encourages a "let's write short trivial functions" 
mentality.
Then whilst it is possible to typedef basic types, it's not a very
sophisticated system. Most C programs use mainly basic types and pointers to
basic types. So this means functions tend to be reusable. What I mean is
that typically a C programmer will write circle_area(double r) rather than
myCircleType::getArea(). The first function can be cut and pasted into any
code that uses circles, the second function isn't reusable unless you pull
in the entire myCircleType suite, which you are unlikely to want to do.
 
Finally, you've got the static keyword, which puts functions into file scope.
So the C programmer can put in a strdup(), for example, without worrying about
exporting symbols. OK a bad example because strdup is in reserved namespace,
but the namespace was reserved because of precisely that problem.

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

#42137

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Keith Thompson <kst-u@mib.org> writes:
>>>This is comp.lang.c; so, when someone asks about »goto«, we assume he
>>>refers to »goto in C«. In C, we (except beginners) write short functions.
>>I'm not aware of any particular connection between writing short
>>functions and the C langauge.
>
>   On the World Wide Web I found a page »
>
> 17. Style
> comp.lang.c FAQ list ·
>
>   «...»
>
> Most observations or "rules" about programming style (
>
>   «...»
>
> functions should fit on one page, etc.) usually work better as
> guidelines than rules
>
>   «. So it says that »functions should fit on one page« in
>   »comp.lang.c« works/worked as a »guideline«. It should not
>   be followed slavishly as a rule, but as a guideline. While
>   there might be legitimate exception, this is the general idea.
>   The Web page mentions »comp.lang.c«, I wrote »we« above.
>
>   We here in comp.lang.c think that »functions should fit on
>   one page« must not be followed slavishly as a rule, but it
>   is a guideline.

You appear to be quoting http://www.c-faq.com/; it would have been good
to mention that.  It's hard to tell just what you're quoting.

But there's nothing C-specific about the advice you cite; it just
happens to be from a site that deals with C.  Would it not be equally
applicable to any other language?

Quoting another followup:
> Keith Thompson <kst-u@mib.org> writes:
> >Are there languages in which long functions are acceptable in your
> >opinion?
> 
>   When I have 32 Kibioctets for both code and data and a 1 MHz
>   processor and a compiler that does not optimize much to
>   implement a complex system, and writing a long function
>   instead of two shorter ones might save me some octets or
>   cycles, I might do it, when this kind of efficiency is important.

That has nothing to do with the language.  In fact, such a small system
is quite likely to be programmed in C.

And I don't feel as strongly as you do that functions should be short.
Each function should do one thing -- but sometimes that one thing is
very complex.  *Arbitrarily* breaking a function down into smaller parts
is not always an improvement.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#42141

On 03/25/2014 10:47 AM, Stefan Ram wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> But there's nothing C-specific about the advice you cite; it just
>> happens to be from a site that deals with C.  Would it not be equally
>> applicable to any other language?
> 
>   I take the context of the newsgroup I am writing in into
>   account.
> 
>   This is comp.lang.c, so I( try to) talk mostly about C.

Yes, but you've been asked to defend an assertion that there is a
C-specific preference for short functions. The reasons supporting such a
claim must be C-specific; the reasons given on that page are not, even
though the site itself is C-specific.
-- 
James Kuyper

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

#42146

In article <C-functions-20140325163248@ram.dialup.fu-berlin.de>,
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>James Kuyper <jameskuyper@verizon.net> writes:
>>Yes, but you've been asked to defend an assertion that there is a
>>C-specific preference for short functions.
>
>  My assertion is that in C we (the majority of educated
>  programmers of today) prefer short functions. I do not wish
>  to make any assertion about whether this holds or does not
>  hold for any other language.
>

I'm sure that Jim & Kiki realized a few posts ago what you meant [*], but
it is their nature that they can't admit it now.  They're committed to
seeing this through on the assumption that their (mis-) understanding of
what you wrote is the only possible interpretation.

It's a lot like the Catholic church.  Their doctrine of infallibility means
that they can never, ever admit to having made a mistake [**].

[*] I.e., that you were simply making a statement of the form: Stop signs
are red.  Note that this doesn't say anything about any other kind of signs
(other types of signs may or may not be red, but this doesn't in any way
impinge on the truth of the assertion that stop signs are red).

[**] In fairness, it must be noted that Kiki (and others like him) do on
occasion admit to being on technical matters (which in the context of this
newsgroup means specifically: interpretation of the C standards documents),
but I have never seen them admit to having misunderstood another posters
post (i.e., intentions).  On these matters, Kiki, James, et al, are, like
the RCC, infallible.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
in the real world."

    - Mary Shafer, NASA Ames Dryden -

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

#42148

On 2014-03-25, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>>Yes, but you've been asked to defend an assertion that there is a
>>C-specific preference for short functions.
>
>   My assertion is that in C we (the majority of educated
>   programmers of today) prefer short functions. I do not wish
>   to make any assertion about whether this holds or does not
>   hold for any other language.

I prefer functions not to be "unnecessarily long".

Sometimes "necessarily long" can mean a thousand lines or more.

If a large function is broken up into a small top function which calls many
smaller ones, but those smaller ones have no caller other than the top
function, then the change is pretty much a waste of effort.

Not only that, but C has poor support for dividing logic into functions.
Breaking up a large function into smaller ones can mean changing the structure
of the code in order to simulate the environment passing that naturally occurs
in a language with nested functions.  What were originally nice, local
variables in the original function turn into some ugly structure or structures
that only exists in order to support the fragmentation of the logic into
multiple functions. These can harm the performance of the function, and also
trade back some of the maintainbility improvement arising from the breakup.

So, it is perfectly okay for some complicated, self-contained piece of logic
which offers no re-usable small pieces to any other part of the program to be
be represented as a big function that works with a bunch of local variables.

Breaking up logic into functions should only be done when:

- some of those functions will be called from more than one place, eliminating
  repetitions.

- some of those functions are useful on their own and will end up being
  called by other functions or modules.

- pieces of the original large code were being selectively dispatched by
  a large switch or if/else ladder, so that when the function is broken up,
  a dispatch based on function pointer indirection can streamline the flow
  and possibly even be faster.

Experienced, mature programmers can handle large functions, and large functions
occur in all advanced, real-world projects.

For instance, the function _dl_map_object_from_fd in the glibc dynamic linker:

   https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c

goes from line 919 to 1623. (Commit 9455df...bef85a).

People always wish that the world conform to their own physical and
intellectual limitations.  Grapes that are out of reach must be sour,
thought the Fox.

Maybe the real principle here is "small functions for small minds".

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

#42167

Kaz Kylheku wrote:
> On 2014-03-25, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> Yes, but you've been asked to defend an assertion that there is a
>>> C-specific preference for short functions.
>>
>>    My assertion is that in C we (the majority of educated
>>    programmers of today) prefer short functions. I do not wish
>>    to make any assertion about whether this holds or does not
>>    hold for any other language.
>
> I prefer functions not to be "unnecessarily long".
>
> Sometimes "necessarily long" can mean a thousand lines or more.
>
> If a large function is broken up into a small top function which calls many
> smaller ones, but those smaller ones have no caller other than the top
> function, then the change is pretty much a waste of effort.

Not if you are unit testing the functions, which I guess counts as them 
having more than one caller...  I have never seen or written long 
functions in code developed using TDD.

-- 
Ian Collins

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

#42174

On Tuesday, March 25, 2014 4:14:58 PM UTC, Kaz Kylheku wrote:
> 
> Maybe the real principle here is "small functions for small minds".
>
Procedural decomposition is largely for the benefit of the programmer, not the
machine. 
I'll happily write trivial little functions. They often make code clearer.
red = clamp(red, 0, 255)

is obvious, writing it out as two ternary expressions obscures what you are
doing. 
 
If you've got difficulty breaking up large functions, the secret is often
to declare structures to hold related units of data. Functions then naturally
operate on those structures. They're not reusable, of course, but they do
make logical sense. For example if you're doing a flood fill, you can have 
the border pixel queue as a struct QUEUE. All the memory management and
circular buffer code is abstracted, and you can see the basic logic.
Since structs can be declared in file scope, you're not polluting namespace.

  

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

#42415

On 25-Mar-14 11:14, Kaz Kylheku wrote:
> On 2014-03-25, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> Yes, but you've been asked to defend an assertion that there is
>>> a C-specific preference for short functions.
>> 
>> My assertion is that in C we (the majority of educated programmers
>> of today) prefer short functions. I do not wish to make any
>> assertion about whether this holds or does not hold for any other
>> language.
> 
> I prefer functions not to be "unnecessarily long".
> 
> Sometimes "necessarily long" can mean a thousand lines or more.

I've never run across such a case.

> If a large function is broken up into a small top function which
> calls many smaller ones, but those smaller ones have no caller other
> than the top function, then the change is pretty much a waste of
> effort.

Not at all.  You can test the smaller functions in isolation and remove
their complexity from the top-level function; that itself has value,
even if the compiler just ends up inlining them.

Also, massive functions imply that your function is doing too many
things, which is inherently problematic and difficult to test or
troubleshoot; it is often better to create a set of small but related
functions, which then call a common set of helper functions.

> Not only that, but C has poor support for dividing logic into
> functions. Breaking up a large function into smaller ones can mean
> changing the structure of the code in order to simulate the
> environment passing that naturally occurs in a language with nested
> functions.  What were originally nice, local variables in the
> original function turn into some ugly structure or structures that
> only exists in order to support the fragmentation of the logic into 
> multiple functions.

How did all that state get into the top-level function, though?  Use the
same mechanism to pass (a portion of) that state to the helper functions.

> Breaking up logic into functions should only be done when:
> 
> - some of those functions will be called from more than one place,
> eliminating repetitions.

Unit tests mean _every_ function is called from at least two places.

> - some of those functions are useful on their own and will end up
> being called by other functions or modules.

That's nice but not necessary.

> - pieces of the original large code were being selectively dispatched
> by a large switch or if/else ladder, so that when the function is
> broken up, a dispatch based on function pointer indirection can
> streamline the flow and possibly even be faster.

If you have a fairly uniform dispatch loop that can use such a
structure, sure.  Many times, you can't.

Still, if the cases are more than a few lines each, I prefer to put the
code in a separate function, even if that's the only caller (besides the
unit test, of course).

> Experienced, mature programmers can handle large functions,

Experience and maturity cannot overcome the inherent limit on the amount
of information that can be kept in short-term memory.

> and large functions occur in all advanced, real-world projects.

That doesn't mean they're a good idea.

> For instance, the function _dl_map_object_from_fd in the glibc
> dynamic linker:
> 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c
> 
> goes from line 919 to 1623. (Commit 9455df...bef85a).

A lot of that is whitespace, preprocessor directives or comments.  Also,
that function clearly does a sequence of operations that could have been
broken up into helper functions--even if it were the only caller.  My
bet is that it started out a lot smaller but grew over time as features
and special cases (or bug fixes) were added, a series of straws that
should have broken the camel's back long ago.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#42417

On 03/31/2014 03:05 PM, Stephen Sprunk wrote:
> On 25-Mar-14 11:14, Kaz Kylheku wrote:
...
> Unit tests mean _every_ function is called from at least two places.

That depends upon how you define unit tests. For purposes of unit
testing, I treat functions with internal linkage as part of the
function(s) with external linkage in the same translation unit that
(directly or indirectly) call them. If they have any feature which
cannot be properly tested through calls to those externally linked
functions, then that generally means that the feature is either
unnecessary or at least badly designed.

...
>> Experienced, mature programmers can handle large functions,
> 
> Experience and maturity cannot overcome the inherent limit on the amount
> of information that can be kept in short-term memory.

No, but it can dramatically increase that limit. Well-designed programs
stress your short-term memory capacity much less than poorly designed
programs, because they're easier to understand.

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

#42583

On 31-Mar-14 14:20, James Kuyper wrote:
> On 03/31/2014 03:05 PM, Stephen Sprunk wrote:
>> Unit tests mean _every_ function is called from at least two places.
> 
> That depends upon how you define unit tests. For purposes of unit
> testing, I treat functions with internal linkage as part of the
> function(s) with external linkage in the same translation unit that
> (directly or indirectly) call them. If they have any feature which
> cannot be properly tested through calls to those externally linked
> functions, then that generally means that the feature is either
> unnecessary or at least badly designed.

To me, the purpose of unit testing is to prove the code is correct (as
defined by the design docs), and one cannot prove a function is correct
until you've proven that all the functions it _calls_ are correct.  I've
chased down too many bugs where function X calls function Y with an
invalid argument and got a result that seemed reasonable--until one day
(or once in a blue moon) it didn't.  If you test function Y, that's one
less thing to worry about when testing (or troubleshooting) function X.

>>> Experienced, mature programmers can handle large functions,
>>
>> Experience and maturity cannot overcome the inherent limit on the amount
>> of information that can be kept in short-term memory.
> 
> No, but it can dramatically increase that limit. Well-designed programs
> stress your short-term memory capacity much less than poorly designed
> programs, because they're easier to understand.

Fair enough, though I think of "large" in terms of complexity rather
than absolute size.  A short, complex function can test my mental limits
more than a long, simple one; the former is also more likely to contain
hidden bugs, and that seems like inherently bad design.

For an example, just look at the IOCCC; most submissions are mercifully
short yet more mentally taxing than a typical real-world program that's
ten or even a hundred times their size.  And I still don't understand
that "RSA in 5 lines" Perl T-shirt, which puts even most IOCCC code to
shame.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#42586

On 04/04/2014 03:56 PM, Stephen Sprunk wrote:
> On 31-Mar-14 14:20, James Kuyper wrote:
>> On 03/31/2014 03:05 PM, Stephen Sprunk wrote:
>>> Unit tests mean _every_ function is called from at least two places.
>>
>> That depends upon how you define unit tests. For purposes of unit
>> testing, I treat functions with internal linkage as part of the
>> function(s) with external linkage in the same translation unit that
>> (directly or indirectly) call them. If they have any feature which
>> cannot be properly tested through calls to those externally linked
>> functions, then that generally means that the feature is either
>> unnecessary or at least badly designed.
> 
> To me, the purpose of unit testing is to prove the code is correct (as
> defined by the design docs), and one cannot prove a function is correct
> until you've proven that all the functions it _calls_ are correct.

True, but if Y can only be called by X, that doesn't prevent you from
testing Y; it just means that you have to test Y by calling X. I've
written more than a few such test drivers. In my experience, if there's
a good reason for giving Y internal linkage, the fact that it's not
directly callable by the test driver is seldom a serious barrier to
testing it.

...
>> ... Well-designed programs
>> stress your short-term memory capacity much less than poorly designed
>> programs, because they're easier to understand.
> 
> Fair enough, though I think of "large" in terms of complexity rather
> than absolute size. ...

I can agree with that; greater size allows greater complexity, but it
does not mandate it. However, as I said earlier, most of the
uncomplicated large functions I've ever seen were either reading into or
writing from badly designed data structures.

> ... A short, complex function can test my mental limits
> more than a long, simple one; the former is also more likely to contain
> hidden bugs, and that seems like inherently bad design.
> 
> For an example, just look at the IOCCC; most submissions are mercifully
> short yet more mentally taxing than a typical real-world program that's
> ten or even a hundred times their size.  And I still don't understand
> that "RSA in 5 lines" Perl T-shirt, which puts even most IOCCC code to
> shame.

Does the expanded version with annotations at the bottom of
<http://www.cypherspace.org/rsa/pureperl.html> help? I haven't bothered
to try to understand it, but it doesn't look that bad (unless you don't
know perl, of course).

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

#42591

Stefan Ram wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> I can agree with that; greater size allows greater complexity, but it
>> does not mandate it. However, as I said earlier, most of the
>> uncomplicated large functions I've ever seen were either reading into or
>> writing from badly designed data structures.
>
>    Once I was assigned to write a C++ interface to a specific
>    database. I started by writing a class for each table.
>
>    Someone who saw my code was horrified by the »unnecessary
>    complexity« of my code.
>
>    It seems to me that he measured complexity by »number of
>    classes«. Since I had written many classes that was a lot of
>    complexity to him.
>
>    I measured complexity by »number of rules«. I had one rule:
>    »One class per table with the name of the class being the
>    name of that table.« So, to me, the complexity was very low.

I hope you won that one!

I've seen too many cases in both C and C++ where the database is the 
"object" and not the database contents.
-- 
Ian Collins

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

#42592

On 4 Apr 2014 21:20:35 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>James Kuyper <jameskuyper@verizon.net> writes:
>>I can agree with that; greater size allows greater complexity, but it
>>does not mandate it. However, as I said earlier, most of the
>>uncomplicated large functions I've ever seen were either reading into or
>>writing from badly designed data structures.
>
>  Once I was assigned to write a C++ interface to a specific
>  database. I started by writing a class for each table.
>
>  Someone who saw my code was horrified by the »unnecessary
>  complexity« of my code.
>
>  It seems to me that he measured complexity by »number of
>  classes«. Since I had written many classes that was a lot of
>  complexity to him.
>
>  I measured complexity by »number of rules«. I had one rule:
>  »One class per table with the name of the class being the
>  name of that table.« So, to me, the complexity was very low.

I would probably be equally horrified and not just because of the
large number of classes, it would be simply that your "rule" is most
likely doomed. <g>

Need to read up on Object Relational Mapping. There are exceptions
where such a scheme might be useful, but doubtful until the
alternatives have been explored and "ruled-out". (Pun intended.)

C++ specifics are OT here, but whether discussing objects/methods or
functions, it has always been a rather universal rule or thumb that
any time an abnormally large number have been created for "external"
consumption of a single resource "complexity" has risen exponentially
and alarm bells should be going off.

-ralph

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

#42593

ralph wrote:
> On 4 Apr 2014 21:20:35 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> I can agree with that; greater size allows greater complexity, but it
>>> does not mandate it. However, as I said earlier, most of the
>>> uncomplicated large functions I've ever seen were either reading into or
>>> writing from badly designed data structures.
>>
>>   Once I was assigned to write a C++ interface to a specific
>>   database. I started by writing a class for each table.
>>
>>   Someone who saw my code was horrified by the »unnecessary
>>   complexity« of my code.
>>
>>   It seems to me that he measured complexity by »number of
>>   classes«. Since I had written many classes that was a lot of
>>   complexity to him.
>>
>>   I measured complexity by »number of rules«. I had one rule:
>>   »One class per table with the name of the class being the
>>   name of that table.« So, to me, the complexity was very low.
>
> I would probably be equally horrified and not just because of the
> large number of classes, it would be simply that your "rule" is most
> likely doomed. <g>
>
> Need to read up on Object Relational Mapping. There are exceptions
> where such a scheme might be useful, but doubtful until the
> alternatives have been explored and "ruled-out". (Pun intended.)
>
> C++ specifics are OT here, but whether discussing objects/methods or
> functions, it has always been a rather universal rule or thumb that
> any time an abnormally large number have been created for "external"
> consumption of a single resource "complexity" has risen exponentially
> and alarm bells should be going off.

The complexity is inherent in the problem.  If your database has a 
hundred tables, whether you choose to have mega database instance with a 
thousand functions or a hundred content focused instances with ten 
functions you still have the same complexity.  How you manage the 
complexity and express the interface to the content is the art of design.

If my client module only cares about the data in tables 36 and 42, I 
know which style of interface I prefer to have to understand.

-- 
Ian Collins

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

#42742

On 04-Apr-14 16:11, James Kuyper wrote:
> On 04/04/2014 03:56 PM, Stephen Sprunk wrote:
>> On 31-Mar-14 14:20, James Kuyper wrote:
>>> On 03/31/2014 03:05 PM, Stephen Sprunk wrote:
>>>> Unit tests mean _every_ function is called from at least two
>>>> places.
>>> 
>>> That depends upon how you define unit tests. For purposes of
>>> unit testing, I treat functions with internal linkage as part of
>>> the function(s) with external linkage in the same translation
>>> unit that (directly or indirectly) call them. If they have any
>>> feature which cannot be properly tested through calls to those
>>> externally linked functions, then that generally means that the
>>> feature is either unnecessary or at least badly designed.
>> 
>> To me, the purpose of unit testing is to prove the code is correct
>> (as defined by the design docs), and one cannot prove a function is
>> correct until you've proven that all the functions it _calls_ are
>> correct.
> 
> True, but if Y can only be called by X, that doesn't prevent you
> from testing Y; it just means that you have to test Y by calling X.
> I've written more than a few such test drivers. In my experience, if
> there's a good reason for giving Y internal linkage, the fact that
> it's not directly callable by the test driver is seldom a serious
> barrier to testing it.

You can only thoroughly test Y if you can prod X into calling Y with all
possible (or at least interesting) values.  If X is well-written, it may
reject or avoid bug-triggering values before they get passed to Y, so
you don't know Y can actually handle them (i.e. fail) correctly, and you
don't get to test X's handling of Y's failure.

>>> ... Well-designed programs stress your short-term memory capacity
>>> much less than poorly designed programs, because they're easier
>>> to understand.
>> 
>> Fair enough, though I think of "large" in terms of complexity
>> rather than absolute size. ...
> 
> I can agree with that; greater size allows greater complexity, but
> it does not mandate it. However, as I said earlier, most of the 
> uncomplicated large functions I've ever seen were either reading into
> or writing from badly designed data structures.

That's one common case, but not the only one I've encountered.

>> ... A short, complex function can test my mental limits more than a
>> long, simple one; the former is also more likely to contain hidden
>> bugs, and that seems like inherently bad design.
>> 
>> For an example, just look at the IOCCC; most submissions are
>> mercifully short yet more mentally taxing than a typical real-world
>> program that's ten or even a hundred times their size.  And I still
>> don't understand that "RSA in 5 lines" Perl T-shirt, which puts
>> even most IOCCC code to shame.
> 
> Does the expanded version with annotations at the bottom of 
> <http://www.cypherspace.org/rsa/pureperl.html> help? I haven't
> bothered to try to understand it, but it doesn't look that bad
> (unless you don't know perl, of course).

I've seen the annotations and they do help, but it's complex enough that
I can't keep the entire thing in my head at once.  That was necessary to
fit it on a T-shirt (or signature), but in another context it'd be bad
design.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#42744

On 04/09/2014 03:30 PM, Stephen Sprunk wrote:
> On 04-Apr-14 16:11, James Kuyper wrote:
>> On 04/04/2014 03:56 PM, Stephen Sprunk wrote:
>>> On 31-Mar-14 14:20, James Kuyper wrote:
>>>> On 03/31/2014 03:05 PM, Stephen Sprunk wrote:
>>>>> Unit tests mean _every_ function is called from at least two
>>>>> places.
>>>>
>>>> That depends upon how you define unit tests. For purposes of
>>>> unit testing, I treat functions with internal linkage as part of
>>>> the function(s) with external linkage in the same translation
>>>> unit that (directly or indirectly) call them. If they have any
>>>> feature which cannot be properly tested through calls to those
>>>> externally linked functions, then that generally means that the
>>>> feature is either unnecessary or at least badly designed.
>>>
>>> To me, the purpose of unit testing is to prove the code is correct
>>> (as defined by the design docs), and one cannot prove a function is
>>> correct until you've proven that all the functions it _calls_ are
>>> correct.
>>
>> True, but if Y can only be called by X, that doesn't prevent you
>> from testing Y; it just means that you have to test Y by calling X.
>> I've written more than a few such test drivers. In my experience, if
>> there's a good reason for giving Y internal linkage, the fact that
>> it's not directly callable by the test driver is seldom a serious
>> barrier to testing it.
> 
> You can only thoroughly test Y if you can prod X into calling Y with all
> possible (or at least interesting) values.  If X is well-written, it may
> reject or avoid bug-triggering values before they get passed to Y, so
> you don't know Y can actually handle them (i.e. fail) correctly, and you
> don't get to test X's handling of Y's failure.

As I said above, I consider X and Y to be a single routine for purposes
of testing. I seen no practical distinction between:

    int X1(int a; int b)
    {
        if(b)
            return a/b;
        else
            return INT_MAX;
    }

and

    static int Y(a, b) { return a/b; }

    int X2 (int a; int b)
    {
        if(b)
            return Y(a,b);
        else
            return INT_MAX;
    }

Y(1,0) would fail; but I don't consider that a defect, since Y() has
internal linkage, and no pointer to Y() is ever passed out of the same
translation unit (TU) where it is defined. Therefore, it can only be
called from within the same TU. Every call to Y() from within the same
TU is protected against having the second argument be 0, so Y() is
relieved of it's responsibility for validating b.

Therefore, I would consider a complete unit test of X1() to also be an
entirely acceptable unit test for X2()+Y(), even though there's no way
for the test driver to call Y(1,0).

This is obviously a simplified example, merely to explain the
equivalence I'm talking about; it is NOT intended to demonstrate a
plausible reason for creating Y() - there is no such reason in this
example. Almost identical blocks of code occurring in several different
locations within X(), and nowhere else, is one typical situation where I
would split off a separate static function for such purposes.

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

#42746

On Wednesday, April 9, 2014 9:37:57 PM UTC+1, James Kuyper wrote:
> 
> As I said above, I consider X and Y to be a single routine for purposes
> of testing. I seen no practical distinction between:
> 
>     int X1(int a; int b)
>     {
>         if(b)
>             return a/b;
>         else
>             return INT_MAX;
>     }
> 
> and
> 
>     static int Y(a, b) { return a/b; }
>
>     int X2 (int a; int b) 
>     {
>         if(b)
>             return Y(a,b);
>         else
>             return INT_MAX;
>     }
> 
A common real example is

void setpixel(unsigned char *image, int width, int height, int x, int y, colour col)

and

void setpixel_checked(unsigned char *image, int width, int height, int x, int y, colour col)

tests for out of bounds are often quite expensive.

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

#42594

Stephen Sprunk <stephen@sprunk.org> writes:

> On 31-Mar-14 14:20, James Kuyper wrote:
>> On 03/31/2014 03:05 PM, Stephen Sprunk wrote:
>>> Unit tests mean _every_ function is called from at least two places.
>> 
>> That depends upon how you define unit tests. For purposes of unit
>> testing, I treat functions with internal linkage as part of the
>> function(s) with external linkage in the same translation unit that
>> (directly or indirectly) call them. If they have any feature which
>> cannot be properly tested through calls to those externally linked
>> functions, then that generally means that the feature is either
>> unnecessary or at least badly designed.
>
> To me, the purpose of unit testing is to prove the code is correct (as
> defined by the design docs), and one cannot prove a function is correct
> until you've proven that all the functions it _calls_ are correct.  I've
> chased down too many bugs where function X calls function Y with an
> invalid argument and got a result that seemed reasonable--until one day
> (or once in a blue moon) it didn't.  If you test function Y, that's one
> less thing to worry about when testing (or troubleshooting) function X.

That's a lot of words for "sw has bugs and you need to test it".

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

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

#42422

Stephen Sprunk wrote:
> On 25-Mar-14 11:14, Kaz Kylheku wrote:
>
>> For instance, the function _dl_map_object_from_fd in the glibc
>> dynamic linker:
>>
>> https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c
>>
>> goes from line 919 to 1623. (Commit 9455df...bef85a).
>
> A lot of that is whitespace, preprocessor directives or comments.  Also,
> that function clearly does a sequence of operations that could have been
> broken up into helper functions--even if it were the only caller.  My
> bet is that it started out a lot smaller but grew over time as features
> and special cases (or bug fixes) were added, a series of straws that
> should have broken the camel's back long ago.

That function appears to be a classic case of the code rot that occurs 
when functionality as added without any thought to improving the design. 
  One of the things I found surprisingly hard when managing development 
teams was getting programmers to refactor code before updating it.  It's 
all too easy just to pile on more functionality.  This is usually a 
symptom of poor management not allowing time for code improvements and a 
lack of unit tests which support refactoring.

-- 
Ian Collins

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

Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8  Next page →

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

csiph-web