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

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

Code for strtol/strtoul

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

Contents

  Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-21 12:09 +0100
    Re: Code for strtol/strtoul Bartc <bc@freeuk.com> - 2015-03-21 11:33 +0000
      Re: Code for strtol/strtoul Bartc <bc@freeuk.com> - 2015-03-21 11:47 +0000
      Re: Code for strtol/strtoul Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-21 15:58 +0000
    Re: Code for strtol/strtoul Lőrinczy Zsigmond <nospam@for.me> - 2015-03-21 16:10 +0100
      Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-21 16:34 +0100
        Re: Code for strtol/strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-21 16:10 +0000
      Re: Code for strtol/strtoul James Kuyper <jameskuyper@verizon.net> - 2015-03-21 12:53 -0400
      Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 14:18 -0700
        Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-21 22:46 +0100
          Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 15:23 -0700
            Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-21 23:42 +0100
              Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 16:06 -0700
                Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 00:29 +0100
                  Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 20:18 -0700
        Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-21 15:54 -0700
          Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 08:34 +0100
          Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 19:42 -0700
            Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-25 10:40 -0700
              Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:17 -0700
                Re: Code for strtol/strtoul Keith Thompson <kst-u@mib.org> - 2015-03-25 20:27 -0700
                  Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:08 -0700
    Re: Code for strtol/strtoul Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-21 15:53 +0000
      Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 21:50 -0700
        Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-25 06:54 +0100
          Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-25 19:18 +1300
            Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-25 09:57 +0100
              Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-26 07:07 +1300
                Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-26 14:22 +1300
                  Re: Code for strtol/strtoul asetofsymbols@gmail.com - 2015-03-26 00:17 -0700
                    Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-28 12:07 +1300
                    Re: Code for strtol/strtoul asetofsymbols@gmail.com - 2015-03-28 02:53 -0700
          Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:19 -0700
          Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 16:13 -0700
        Re: Code for strtol/strtoul Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-25 13:42 +0000
          Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 17:20 -0700
            Re: Code for strtol/strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-26 04:16 +0000
              Re: Code for strtol/strtoul asetofsymbols@gmail.com - 2015-03-26 00:27 -0700
                Re: Code for strtol/strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-26 13:44 +0000
                  Re: Code for strtol/strtoul fir <profesor.fir@gmail.com> - 2015-03-26 07:13 -0700
                  Re: Code for strtol/strtoul asetofsymbols@gmail.com - 2015-03-26 08:30 -0700
                    Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-29 15:13 +0000
              Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:47 -0700
            Re: Code for strtol/strtoul Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-26 15:00 +0000
              Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-27 07:12 +1300
                Re: Code for strtol/strtoul Bartc <bc@freeuk.com> - 2015-03-26 19:11 +0000
                  Re: Code for strtol/strtoul Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-26 15:09 -0700
                    Re: Code for strtol/strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-26 22:13 +0000
                      Re: Code for strtol/strtoul Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-26 15:20 -0700
                    Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-30 09:59 +0000
                      Re: Code for strtol/strtoul Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-30 06:38 -0700
                        Re: Code for strtol/strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 14:41 +0100
                          Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-04-06 12:52 +0000
                  Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-27 18:07 +1300
                    Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-29 15:17 +0000
                      Re: Code for strtol/strtoul Kaz Kylheku <kaz@kylheku.com> - 2015-03-29 15:26 +0000
                      Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-30 07:09 +1300
                        Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-30 10:02 +0000
                    Re: Code for strtol/strtoul Bartc <bc@freeuk.com> - 2015-03-29 18:53 +0100
              Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 15:38 -0700
    Re: Code for strtol/strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-21 16:48 -0500
    Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-22 20:45 +1300
      Re: Code for strtol/strtoul Ike Naar <ike@iceland.freeshell.org> - 2015-03-23 09:40 +0000
        Re: Code for strtol/strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 09:46 +0000
          Re: Code for strtol/strtoul Reinhardt Behm <rbehm@hushmail.com> - 2015-03-23 18:44 +0800
          Re: Code for strtol/strtoul Les Cargill <lcargill99@comcast.com> - 2015-03-23 20:29 -0500
            Re: Code for strtol/strtoul Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 08:12 +0000
        Re: Code for strtol/strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 05:27 -0500
        Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-24 07:03 +1300
          Re: Code for strtol/strtoul Ike Naar <ike@iceland.freeshell.org> - 2015-03-23 22:40 +0000
            Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-24 17:17 +1300
              Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 21:42 -0700
                Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-25 17:55 +1300
                  Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:43 -0700
                    Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-26 14:15 +1300
                    Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 14:53 -0700
                      Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-29 11:04 +1300
                        Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 12:34 -0700
                          Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-31 21:20 +1300
    Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 22:31 -0700
      Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-25 19:30 +1300
        Re: Code for strtol/strtoul Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:24 -0700
    Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-25 22:43 +0100
      Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-27 19:18 +1300
      Re: Code for strtol/strtoul Steve Thompson <stevet810@gmail.com> - 2015-03-27 15:02 +0000
        Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-27 16:10 +0100
          Re: Code for strtol/strtoul Steve Thompson <stevet810@gmail.com> - 2015-03-27 22:44 +0000
          Re: Code for strtol/strtoul raltbos@xs4all.nl (Richard Bos) - 2015-03-29 15:18 +0000
            Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 17:35 +0200
      Re: Code for strtol/strtoul Robert Wessel <robertwessel2@yahoo.com> - 2015-03-28 03:57 -0500
        Re: Code for strtol/strtoul jacob navia <jacob@jacob.remcomp.fr> - 2015-03-28 14:09 +0100
    Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-28 22:58 +1300
      Re: Code for strtol/strtoul Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-28 11:33 +0000
        Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-29 08:49 +1300
          Re: Code for strtol/strtoul Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-28 22:11 +0000
            Re: Code for strtol/strtoul Ian Collins <ian-news@hotmail.com> - 2015-03-29 11:30 +1300

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

#59024

To Kaz:
I quote ok...
I used convention:
WHO Wrote: <<text he/she wrote>>

There is nothing to understand...

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

#59208

asetofsymbols@gmail.com wrote:

> I quote ok...

Not even close.

Richard

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

#59152

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2015-03-26, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Greg Martin <greg.at.softsprocket@dot.com> writes:
>>
>>> On 2015-03-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>>> Greg Martin <greg.at.softsprocket@dot.com> writes:
>>>>
>>>>> On 2015-03-21, jacob navia <jacob@jacob.remcomp.fr> wrote:
>>>>>> After some days working in those functions, I would like to
>>>>>> share this work with you.  I think discussing C is as
>>>>>> interesting as discussing UFOs ( :-) ), because there some
>>>>>> interesting issues in this code.  [snip a few questions]
>>>>>>
>>>>>> What about other stuff like code readability variable names,
>>>>>> whatever.
>>>>>
>>>>> Excellent readability.  Full points for the comments.
>>>>
>>>> I find this response astonishing.  The central function
>>>> is 179 lines long.  Any benefit from the content of the
>>>> comments is more than lost in the maze of the long
>>>> function body.
>>>
>>> So you found it hard to read then?
>>
>> I found it hard to comprehend in the sense that I felt like it
>> would have taken a lot of effort to convince myself that what it
>> was doing is correct.  That's probably my most important metric -
>> how hard do I have to work to convince myself that the code is
>> correct.
>
> This metric is amazingly broadly applicable;  it's the underlying
> justification for any effective methodology, tool or practice.
> [snip elaboration]

I think you're overstating the case a bit, but I appreciate the
appreciation.

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

#59021

On 2015-03-26, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Greg Martin <greg.at.softsprocket@dot.com> writes:
>
>> On 2015-03-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>> Greg Martin <greg.at.softsprocket@dot.com> writes:
>>>
>>>> On 2015-03-21, jacob navia <jacob@jacob.remcomp.fr> wrote:
>>>>> After some days working in those functions, I would like to share
>>>>> this work with you.  I think discussing C is as interesting as
>>>>> discussing UFOs ( :-) ), because there some interesting issues in
>>>>> this code.  [snip a few questions]
>>>>>
>>>>> What about other stuff like code readability variable names,
>>>>> whatever.
>>>>
>>>> Excellent readability.  Full points for the comments.
>>>
>>> I find this response astonishing.  The central function
>>> is 179 lines long.  Any benefit from the content of the
>>> comments is more than lost in the maze of the long
>>> function body.
>>
>> So you found it hard to read then?
>
> I found it hard to comprehend in the sense that I felt like it
> would have taken a lot of effort to convince myself that what it
> was doing is correct.  That's probably my most important metric -
> how hard do I have to work to convince myself that the code is
> correct.
>

Yes, I wouldn't argue that. I didn't try to assure myself it was
correct because it seemed more effort then I was prepared to bring to
some code for a platform I never use.

> Also, for me, I find it hurts a lot more than it helps to
> intermingle comments of specification and executable code.  This
> style of commenting is one I used a long time ago (in a galaxy
> far, far away from the other side of the universe) when I was
> writing assembly language.  Looking back I see it as more of a
> habit for beginners than a mature development practice.
>

I'm not sure I'd characterize it as a habit for beginners, and not
because I use the style myself; I don't, but I have been been at this 
a long time and have found that anytime best practises become
thoughtless strictures they lose meaning.

I don't write comments longer then a single line in the middle of code
(and rarely that) because I find it to much bother and therefore have to
write code that, to some degree, explains what I'm doing.

>> I can't say that I did, though
>> I don't entirely remember.  If memory serves the comments were
>> placed at the point in the code where the code was they described.
>
> Yes, that's the assembly language style.  The main problem with that
> style is it doesn't scale up (not to mention being a poor match for
> natural cognitive modes, as some important research has shown).
>

I haven't seen that research. Had I read the code without comments I
would have skipped most of it and just hit the buzzer but with the
comments I could understand why he was doing what he was doing, even if
I didn't want to take the time to verify it. 

Perhaps I was operating in an unnatural cognitive mode?

>> Short functions are often preferable but I don't recall finding
>> the function difficult to follow in any way - which I find the
>> true measure of readability.
>
> Without reading the comments, how easily can you understand
> what the function is doing?  How much effort is it to convince
> yourself that the code is correct?  Code that is well-written
> doesn't need comments to achieve these goals.  Incidentally,
> on the term "readability" is one I find means different things
> to different people, and often doesn't capture what I believe
> is a more important aspect, namely comprehensibility.  A given
> piece of code can be easy to read and hard to comprehend, or
> (in some cases) vice versa;  IMO this makes it all the more
> important to distinguish these different aspects (and sometimes
> other aspects as well).

Without the comments I wouldn't bothered, since if memory serves, the 
code wasn't clear to me. I would rather read code that didn't require
comments but I would rather read commented code then impenetrable code
without comments.

I guess to truly decide whether the code was poorly written I would have
had to try to rewrite it in a manner that didn't require comments and I
wasn't about to do that. It undoubtedly would have been improved by being
broken out into smaller pieces and perhaps the points where the comments
were might have been natural break points, though if the functions were
never to be used elsewhere I would have to be convinced the
reorganization was worth the context shift.


-- 
http://www.softsprocket.com

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

#59035

Greg Martin wrote:
>
> I guess to truly decide whether the code was poorly written I would have
> had to try to rewrite it in a manner that didn't require comments and I
> wasn't about to do that. It undoubtedly would have been improved by being
> broken out into smaller pieces and perhaps the points where the comments
> were might have been natural break points, though if the functions were
> never to be used elsewhere I would have to be convinced the
> reorganization was worth the context shift.

I've always considered the rule "if it needs a comment, factor it out" 
to be one of the most important in producing clear code.

I also tend to start a function is a pseudo code manner such as

void f()
{
   doSomething();
   doTheNextThing();
   ...
}

and then fill in the steps as discrete functions.

-- 
Ian Collins

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

#59039

On 26/03/2015 18:12, Ian Collins wrote:
> Greg Martin wrote:
>>
>> I guess to truly decide whether the code was poorly written I would have
>> had to try to rewrite it in a manner that didn't require comments and I
>> wasn't about to do that. It undoubtedly would have been improved by being
>> broken out into smaller pieces and perhaps the points where the comments
>> were might have been natural break points, though if the functions were
>> never to be used elsewhere I would have to be convinced the
>> reorganization was worth the context shift.
>
> I've always considered the rule "if it needs a comment, factor it out"
> to be one of the most important in producing clear code.

Suppose you need to explain why there is an inexplicable +1 offset in an 
expression. What good will it do to put the expression in its own function?

Would you try and shoe-horn the explanation into the name of the function?

-- 
Bartc

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

#59043

On Thursday, March 26, 2015 at 7:12:04 PM UTC, Bart wrote:
> 
> Suppose you need to explain why there is an inexplicable +1 offset in an 
> expression. What good will it do to put the expression in its own function?
> 
> Would you try and shoe-horn the explanation into the name of the function?
> 
double meanx(double *x, int N)
{
   int i;
   double total = 0;
   for(i=0;i<N;i++)
     total += x[i];

   return total / wugginscorrection(N);

}

static int wugginscorrection(int N)
{
   return N + 1;
}

Slightly helpful, no? You can do a web search on wuggins and see
the justification for his correction.

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

#59044

On 26/03/15 22:09, Malcolm McLean wrote:
> On Thursday, March 26, 2015 at 7:12:04 PM UTC, Bart wrote:
>>
>> Suppose you need to explain why there is an inexplicable +1 offset in an
>> expression. What good will it do to put the expression in its own function?
>>
>> Would you try and shoe-horn the explanation into the name of the function?
>>
> double meanx(double *x, int N)
> {
>     int i;
>     double total = 0;
>     for(i=0;i<N;i++)
>       total += x[i];
>
>     return total / wugginscorrection(N);
>
> }
>
> static int wugginscorrection(int N)
> {
>     return N + 1;
> }
>
> Slightly helpful, no? You can do a web search on wuggins and see
> the justification for his correction.

Wouldn't it save time for the people who have to maintain the code if 
you just write the justification once and for all, in a comment?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#59045

On Thursday, March 26, 2015 at 10:13:42 PM UTC, Richard Heathfield wrote:
> On 26/03/15 22:09, Malcolm McLean wrote:
> > On Thursday, March 26, 2015 at 7:12:04 PM UTC, Bart wrote:
> >>
> >> Suppose you need to explain why there is an inexplicable +1 offset in an
> >> expression. What good will it do to put the expression in its own function?
> >>
> >> Would you try and shoe-horn the explanation into the name of the function?
> >>
> > double meanx(double *x, int N)
> > {
> >     int i;
> >     double total = 0;
> >     for(i=0;i<N;i++)
> >       total += x[i];
> >
> >     return total / wugginscorrection(N);
> >
> > }
> >
> > static int wugginscorrection(int N)
> > {
> >     return N + 1;
> > }
> >
> > Slightly helpful, no? You can do a web search on wuggins and see
> > the justification for his correction.
> 
> Wouldn't it save time for the people who have to maintain the code if 
> you just write the justification once and for all, in a comment?
> 
You can assume that anyone competent to maintain the code will
either be familiar with the wuggins correction and know when to
use or, or will want to remedy that lack by reading the literature.

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

#59256

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> static int wugginscorrection(int N)
> {
>    return N + 1;
> }
> 
> Slightly helpful, no? You can do a web search on wuggins and see
> the justification for his correction.

Code which needs a working web connection to be readable is useless.

Now, if "wuggins" were a standard term of trade in the business for
which this code is written, that's another matter. If you read code
written for a specific business, you need to know how this business
works anyway, or you're not going to understand what the code is for
even if it's explained in simple words of one syllable. But even then, I
find the above less readable than a simple

   <statement using an expression> + 1; /* plus wuggins */

It's not even significantly shorter than 

   <statement using an expression> + wugginscorrection(N);


Richard

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

#59269

On Monday, March 30, 2015 at 10:59:52 AM UTC+1, Richard Bos wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> 
> > static int wugginscorrection(int N)
> > {
> >    return N + 1;
> > }
> > 
> > Slightly helpful, no? You can do a web search on wuggins and see
> > the justification for his correction.
> 
> Code which needs a working web connection to be readable is useless.
> 
> Now, if "wuggins" were a standard term of trade in the business for
> which this code is written, that's another matter. If you read code
> written for a specific business, you need to know how this business
> works anyway, or you're not going to understand what the code is for
> even if it's explained in simple words of one syllable. But even then, I
> find the above less readable than a simple
> 
<statement using an expression> + 1; /* plus wuggins */ 

Wuggins has obviously created a derivative of the mean which uses N+1
as the denominator, rather than N. So a Wuggins corrected-mean is zero
for the null case, and it biases the estimate towards zero for small sample
sizes, whilst leaving it essentially unchanged from the arithmetical mean
for large samples.
Wuggins will have written and published a justification in a  statistical journal
somewhere. If our maintaining programmer is competent to maintain
this type of code, we can assume that he's used to reading that type of
literature. He may not have heard of Wuggins, depending on how well-
established the method is. 
But we can't really produce an abstract or précis of Wuggins' work in the
code itself. A comment should probably include a reference to the work -
I wouldn't throw out code that was written as you suggest, but it's not a
specially good method, as someone might comment out the +1 and
leave the "Wuggins' correction" comment in. Then the next person to come
along wonders if the Wuggins correction is to add one to the denominator
(the correct theory) or if a programmer called Wuggins has taken out a bug
in the mean (incorrect but reasonable assumption).
 

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

#59270

On 30/03/15 14:38, Malcolm McLean wrote:

<snip>

>Then the next person to come
> along wonders if the Wuggins correction is to add one to the denominator
> (the correct theory) or if a programmer called Wuggins has taken out a bug
> in the mean (incorrect but reasonable assumption).

That isn't a good reason not to write a comment. It is, however, a good 
reason not to write a crap[1] comment. A comment that can be 
misinterpreted in that way is a crap comment.


[1] technical term.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#59685

Richard Heathfield <rjh@cpax.org.uk> wrote:

> On 30/03/15 14:38, Malcolm McLean wrote:
> 
> >Then the next person to come
> > along wonders if the Wuggins correction is to add one to the denominator
> > (the correct theory) or if a programmer called Wuggins has taken out a bug
> > in the mean (incorrect but reasonable assumption).
> 
> That isn't a good reason not to write a comment. It is, however, a good 
> reason not to write a crap[1] comment. A comment that can be 
> misinterpreted in that way is a crap comment.

Exactly; hence my remark about terms of trade. If this wuggins is not a
term of trade but a private invention of one Wuggins, Esq., then _of
course_ it needs more comments and may indeed need to be functioned out.
But IME, those cases are rather rarer than the more widely understood
ones which require merely a short, concise, but clear comment.

Richard

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

#59058

Bartc wrote:
> On 26/03/2015 18:12, Ian Collins wrote:
>> Greg Martin wrote:
>>>
>>> I guess to truly decide whether the code was poorly written I would have
>>> had to try to rewrite it in a manner that didn't require comments and I
>>> wasn't about to do that. It undoubtedly would have been improved by being
>>> broken out into smaller pieces and perhaps the points where the comments
>>> were might have been natural break points, though if the functions were
>>> never to be used elsewhere I would have to be convinced the
>>> reorganization was worth the context shift.
>>
>> I've always considered the rule "if it needs a comment, factor it out"
>> to be one of the most important in producing clear code.
>
> Suppose you need to explain why there is an inexplicable +1 offset in an
> expression. What good will it do to put the expression in its own function?
>
> Would you try and shoe-horn the explanation into the name of the function?

No.  I'd give the 1 a meaningful name.

-- 
Ian Collins

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

#59209

Ian Collins <ian-news@hotmail.com> wrote:

> Bartc wrote:
> > On 26/03/2015 18:12, Ian Collins wrote:
> >> I've always considered the rule "if it needs a comment, factor it out"
> >> to be one of the most important in producing clear code.
> >
> > Suppose you need to explain why there is an inexplicable +1 offset in an
> > expression. What good will it do to put the expression in its own function?
> >
> > Would you try and shoe-horn the explanation into the name of the function?
> 
> No.  I'd give the 1 a meaningful name.

So you'd

  #define ACCOUNTFORTHESTRINGTERMINATINGNULLCHARACTER 1

?

Ok, no C programmer would expect to need to write a comment to account
for the null terminator... but I've written comments to explain why a
field was a certain size which mentioned the length of one (government-
or similar-dictated) name, the size of a number, _plus that one_.

Sometimes, my point is, it's just simpler and less finicky to write that
number, and an explicating comment, than to #define three constants
which you are only going to use _that one time_, just to add them.

Richard

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

#59212

On 2015-03-29, Richard Bos <raltbos@xs4all.nl> wrote:
> Ian Collins <ian-news@hotmail.com> wrote:
>
>> Bartc wrote:
>> > On 26/03/2015 18:12, Ian Collins wrote:
>> >> I've always considered the rule "if it needs a comment, factor it out"
>> >> to be one of the most important in producing clear code.
>> >
>> > Suppose you need to explain why there is an inexplicable +1 offset in an
>> > expression. What good will it do to put the expression in its own function?
>> >
>> > Would you try and shoe-horn the explanation into the name of the function?
>> 
>> No.  I'd give the 1 a meaningful name.
>
> So you'd
>
>   #define ACCOUNTFORTHESTRINGTERMINATINGNULLCHARACTER 1
>
> ?
>
> Ok, no C programmer would expect to need to write a comment to account
> for the null terminator... but I've written comments to explain why a
> field was a certain size which mentioned the length of one (government-
> or similar-dictated) name, the size of a number, _plus that one_.

The only reason you would ever comment the "1" in the following:

  wchar_t x[FOO_LEN + 1];

is that you're writing a tutorial for complete newbies, in which this
is an example.

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

#59225

Richard Bos wrote:
> Ian Collins <ian-news@hotmail.com> wrote:
>
>> Bartc wrote:
>>> On 26/03/2015 18:12, Ian Collins wrote:
>>>> I've always considered the rule "if it needs a comment, factor it out"
>>>> to be one of the most important in producing clear code.
>>>
>>> Suppose you need to explain why there is an inexplicable +1 offset in an
>>> expression. What good will it do to put the expression in its own function?
>>>
>>> Would you try and shoe-horn the explanation into the name of the function?
>>
>> No.  I'd give the 1 a meaningful name.
>
> So you'd
>
>    #define ACCOUNTFORTHESTRINGTERMINATINGNULLCHARACTER 1
>
> ?

No, I never resort to the preprocessor for such constants...

-- 
Ian Collins

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

#59257

Ian Collins <ian-news@hotmail.com> wrote:

> Richard Bos wrote:
> > Ian Collins <ian-news@hotmail.com> wrote:
> >
> >> Bartc wrote:
> >>> On 26/03/2015 18:12, Ian Collins wrote:
> >>>> I've always considered the rule "if it needs a comment, factor it out"
> >>>> to be one of the most important in producing clear code.
> >>>
> >>> Suppose you need to explain why there is an inexplicable +1 offset in an
> >>> expression. What good will it do to put the expression in its own function?
> >>>
> >>> Would you try and shoe-horn the explanation into the name of the function?
> >>
> >> No.  I'd give the 1 a meaningful name.
> >
> > So you'd
> >
> >    #define ACCOUNTFORTHESTRINGTERMINATINGNULLCHARACTER 1
> >
> > ?
> 
> No, I never resort to the preprocessor for such constants...

:-P

So you'd

  enum random_constants {
    accountforthestringterminatingnullcharacter=1
  };

then?

Or perhaps

  const /* must have const */ long unsigned int
       accountforthestringterminatingnullcharacter = 1;

?

Richard

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

#59223

On 27/03/2015 05:07, Ian Collins wrote:
> Bartc wrote:
>> On 26/03/2015 18:12, Ian Collins wrote:

>>> I've always considered the rule "if it needs a comment, factor it out"
>>> to be one of the most important in producing clear code.
>>
>> Suppose you need to explain why there is an inexplicable +1 offset in an
>> expression. What good will it do to put the expression in its own
>> function?
>>
>> Would you try and shoe-horn the explanation into the name of the
>> function?
>
> No.  I'd give the 1 a meaningful name.

OK, so you'd shoe-horn the explanation into the name! And in the process 
hide whatever value it is you're adding or subtracting.

You source code must be bereft of any numeric literals at all.

I think people like to see small constants such as 1s and 2s being used 
so they know what's happening, but sometimes need to know why, which is 
where the comment comes in:

for (i=0; i<N-1; ++i) ...

This indexes all elements of an N-sized array except the last, 
because... you're processing the i and i+1 elements. Or the last element 
is some sort of sentinel that you don't need to process. Or because at 
this point the last element has an undefined value. Or...

I can't see how you can think up something suitable for that '1' that 
will make sense when written it its place:

for (i=0; i<N-NamedOffset; ++i) ...

Or may be you can replace the N-1 by M, where M is set up as:

  M = N-1;

but now you have to explain this! It might be better to explain what is 
being done by the loop, but you don't seem to like any comments at all.

-- 
Bartc

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

#59180

Greg Martin <greg.at.softsprocket@dot.com> writes:

> [lots of interesting stuff]

I'm writing a short reply now to say you touched on a lot of
different points which I found interesting and have more to
say about, but can't right now.  I hope to write a longer
and more comprehensive response soon.

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

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

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

csiph-web