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

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

guidelines for pointer check

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

Contents

  guidelines for pointer check Thiago Adams <thiago.adams@gmail.com> - 2016-12-29 12:53 -0800
    Re: guidelines for pointer check Ian Collins <ian-news@hotmail.com> - 2016-12-30 09:58 +1300
    Re: guidelines for pointer check Keith Thompson <kst-u@mib.org> - 2016-12-29 13:39 -0800
      Re: guidelines for pointer check Thiago Adams <thiago.adams@gmail.com> - 2016-12-29 15:24 -0800
        Re: guidelines for pointer check Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-29 19:05 -0500
          Re: guidelines for pointer check Thiago Adams <thiago.adams@gmail.com> - 2016-12-30 05:27 -0800
            Re: guidelines for pointer check Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 14:35 +0000
            Re: guidelines for pointer check supercat@casperkitty.com - 2016-12-30 10:38 -0800
          Re: guidelines for pointer check Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:28 -0800
        Re: guidelines for pointer check Keith Thompson <kst-u@mib.org> - 2016-12-29 16:19 -0800
    Re: guidelines for pointer check Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:58 -0800
    guidelines for pointer check asetofsymbols@gmail.com - 2016-12-30 05:35 -0800
    Re: guidelines for pointer check raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:47 +0000
    Re: guidelines for pointer check Noob <root@127.0.0.1> - 2017-01-02 14:19 +0100
      Re: guidelines for pointer check David Brown <david.brown@hesbynett.no> - 2017-01-02 14:28 +0100
        Re: guidelines for pointer check Noob <root@127.0.0.1> - 2017-01-02 17:35 +0100
          Re: Using == operator Noob <root@127.0.0.1> - 2017-01-02 19:03 +0100
            Re: Using == operator David Brown <david.brown@hesbynett.no> - 2017-01-02 23:41 +0100
              Re: Using == operator Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 14:54 -0800
                Re: Using == operator Keith Thompson <kst-u@mib.org> - 2017-01-02 15:57 -0800
                  Re: Using == operator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-01-03 16:31 -0500
                    Re: Using == operator Keith Thompson <kst-u@mib.org> - 2017-01-03 14:06 -0800
                      Re: Using == operator Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-03 14:44 -0800
                        Re: Using == operator Keith Thompson <kst-u@mib.org> - 2017-01-03 15:05 -0800
                          Re: Using == operator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-04 16:42 +0000
                            Re: Using == operator Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 11:46 -0800
                        Re: Using == operator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-01-03 21:22 -0700
                      Re: Using == operator supercat@casperkitty.com - 2017-01-03 15:23 -0800
                        Re: Using == operator Keith Thompson <kst-u@mib.org> - 2017-01-03 15:30 -0800
                          Re: Using == operator supercat@casperkitty.com - 2017-01-03 16:02 -0800
                            Re: Using == operator Keith Thompson <kst-u@mib.org> - 2017-01-03 16:30 -0800
                              Re: Using == operator Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 11:26 -0800
                        Re: Using == operator raltbos@xs4all.nl (Richard Bos) - 2017-01-04 09:55 +0000
                          Re: Using == operator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-04 16:49 +0000
                            Re: Using == operator raltbos@xs4all.nl (Richard Bos) - 2017-01-10 01:28 +0000
                              Re: Using == operator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-01-09 19:12 -0700
                              Re: Using == operator Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 09:12 -0800
                            Re: Using == operator Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 09:54 -0800
                Re: Using == operator raltbos@xs4all.nl (Richard Bos) - 2017-01-03 21:08 +0000
                  Re: Using == operator Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 06:44 -0800
    Re: guidelines for pointer check Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2017-01-04 08:54 -0800
      Re: guidelines for pointer check Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:51 -0800

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

#101039 — Re: Using == operator

On Monday January 2 2017 18:57, in comp.lang.c, "Keith Thompson" <kst-
u@mib.org> wrote:

> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> [...]
>> Also
>>             if(node->next)
>>
>> reads like English.
> 
> Does it?  C has the convention that using a value as a condition
> implicitly compares that value to zero.  English has no such convention.
> 
> For example, suppose I have a bag that may or may not contain any
> apples.  In C, you can say either "if (apple_count != 0)" or
> "if (apple_count)".  In English, "If the number of apples in the
> bag then ..."  doesn't make sense.


"If there are any apples in the bag, then..."


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#101043 — Re: Using == operator

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Monday January 2 2017 18:57, in comp.lang.c, "Keith Thompson" <kst-
> u@mib.org> wrote:
>
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>>> Also
>>>             if(node->next)
>>>
>>> reads like English.
>> 
>> Does it?  C has the convention that using a value as a condition
>> implicitly compares that value to zero.  English has no such convention.
>> 
>> For example, suppose I have a bag that may or may not contain any
>> apples.  In C, you can say either "if (apple_count != 0)" or
>> "if (apple_count)".  In English, "If the number of apples in the
>> bag then ..."  doesn't make sense.
>
>
> "If there are any apples in the bag, then..."

Even if we assume that that corresponds to `if (apple_count)`, what's
the corresponding English for if(node->next)?

-- 
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]

#101049 — Re: Using == operator

On Tuesday, January 3, 2017 at 10:06:27 PM UTC, Keith Thompson wrote:
>
> Even if we assume that that corresponds to `if (apple_count)`, what's
> the corresponding English for if(node->next)?
> 
"If we've the node's next member"

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

#101053 — Re: Using == operator

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, January 3, 2017 at 10:06:27 PM UTC, Keith Thompson wrote:
>>
>> Even if we assume that that corresponds to `if (apple_count)`, what's
>> the corresponding English for if(node->next)?
>> 
> "If we've the node's next member"

If that interpretation works for you, that's fine.  It doesn't work
for me.

What about
    if (apple_count)
vs.
    if (apple_count != 0)
vs.
    if (apple_count > 0)
?  Does the first of those read like English to you?

-- 
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]

#101106 — Re: Using == operator

On Tue, 2017-01-03, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Tuesday, January 3, 2017 at 10:06:27 PM UTC, Keith Thompson wrote:
>>>
>>> Even if we assume that that corresponds to `if (apple_count)`, what's
>>> the corresponding English for if(node->next)?
>>> 
>> "If we've the node's next member"

Or "if the node has a next node".

> If that interpretation works for you, that's fine.  It doesn't work
> for me.

That's the key.  For Malcolm, and for me, it works.  And I thought it
worked for the majority of C programmers -- but I've been surprised
over and over in the past.  The way people think seems to vary
/a lot/, and you don't even have to have old Pascal programmers in the
team to see that.

> What about
>     if (apple_count)
> vs.
>     if (apple_count != 0)
> vs.
>     if (apple_count > 0)
> ?  Does the first of those read like English to you?

Here I think the variable was named by someone aiming for !=.  I would
have written it as

    if(apples)

or if I could keep the variable very local, use the convention that
'n' is a count of limited scope:

    if(n)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#101868 — Re: Using == operator

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Tue, 2017-01-03, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> On Tuesday, January 3, 2017 at 10:06:27 PM UTC, Keith Thompson wrote:
>>>
>>>> Even if we assume that that corresponds to `if (apple_count)`, what's
>>>> the corresponding English for if(node->next)?
>>>
>>> "If we've the node's next member"
>
> Or "if the node has a next node".
>
>> If that interpretation works for you, that's fine.  It doesn't work
>> for me.
>
> That's the key.  For Malcolm, and for me, it works.  And I thought it
> worked for the majority of C programmers -- but I've been surprised
> over and over in the past.  The way people think seems to vary
> /a lot/, and you don't even have to have old Pascal programmers in the
> team to see that.
>
>> What about
>>     if (apple_count)
>> vs.
>>     if (apple_count != 0)
>> vs.
>>     if (apple_count > 0)
>> ?  Does the first of those read like English to you?
>
> Here I think the variable was named by someone aiming for !=.  I would
> have written it as
>
>     if(apples)

Of course it depends on context, but my impression is both of
these names don't adequately express what is being represented.
In various cases it might be, eg, 'apples_eaten', 'apples_sold',
or 'apples_shipped', to better express what quantity the variable
is meant to hold.  Then a usage like

    if(apples_eaten)

reads rather naturally as "if any apples were eaten", which may
suffice to justify leaving '> 0' (or '!= 0') out of the code.


> or if I could keep the variable very local, use the convention that
> 'n' is a count of limited scope:
>
>     if(n)

I very much agree.  Different surrounding conditions often
suggest or allow different naming choices.

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

#101077 — Re: Using == operator

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

> On Tuesday, January 3, 2017 at 10:06:27 PM UTC, Keith Thompson wrote:
>>
>> Even if we assume that that corresponds to `if (apple_count)`, what's
>> the corresponding English for if(node->next)?
>> 
> "If we've the node's next member"

You clearly speak a different dialect of English than I do.

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

#101055 — Re: Using == operator

On Tuesday, January 3, 2017 at 4:06:27 PM UTC-6, Keith Thompson wrote:
> Even if we assume that that corresponds to `if (apple_count)`, what's
> the corresponding English for if(node->next)?

Since every pointer which is used in such a context is required to either
be a valid pointer or a null pointer, the English would be "If the object
pointed to by 'node' has a valid 'next' pointer, then...."  Although the
code is in a literal sense comparing a pointer with a null pointer, such
a comparison is merely the means by which code determines that a pointer is
valid.

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

#101056 — Re: Using == operator

supercat@casperkitty.com writes:
> On Tuesday, January 3, 2017 at 4:06:27 PM UTC-6, Keith Thompson wrote:
>> Even if we assume that that corresponds to `if (apple_count)`, what's
>> the corresponding English for if(node->next)?
>
> Since every pointer which is used in such a context is required to either
> be a valid pointer or a null pointer, the English would be "If the object
> pointed to by 'node' has a valid 'next' pointer, then...."  Although the
> code is in a literal sense comparing a pointer with a null pointer, such
> a comparison is merely the means by which code determines that a pointer is
> valid.

A null pointer is valid in some contexts (including this one), there are
invalid pointers other than the null pointer, and claiming that

    if(node->next)

can be read as

    If the object pointed to by 'node' has a valid 'next' pointer,
    then....

hardly supports the claim that it "reads like English".

-- 
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]

#101059 — Re: Using == operator

On Tuesday, January 3, 2017 at 5:29:49 PM UTC-6, Keith Thompson wrote:
> supercat writes:
> > On Tuesday, January 3, 2017 at 4:06:27 PM UTC-6, Keith Thompson wrote:
> >> Even if we assume that that corresponds to `if (apple_count)`, what's
> >> the corresponding English for if(node->next)?
> >
> > Since every pointer which is used in such a context is required to either
> > be a valid pointer or a null pointer, the English would be "If the object
> > pointed to by 'node' has a valid 'next' pointer, then...."  Although the
> > code is in a literal sense comparing a pointer with a null pointer, such
> > a comparison is merely the means by which code determines that a pointer is
> > valid.
> 
> A null pointer is valid in some contexts (including this one), there are
> invalid pointers other than the null pointer, and claiming that
> 
>     if(node->next)
> 
> can be read as
> 
>     If the object pointed to by 'node' has a valid 'next' pointer,
>     then....
> 
> hardly supports the claim that it "reads like English".

I should have said "every pointer is either a valid pointer *to an object*
or a null pointer" but the principle holds.  So if you prefer, the test
is for whether field "next" points to any object, as distinct from testing
whether field "next" holds the only value it could hold without pointing
to an object.

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

#101065 — Re: Using == operator

supercat@casperkitty.com writes:
> On Tuesday, January 3, 2017 at 5:29:49 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> > On Tuesday, January 3, 2017 at 4:06:27 PM UTC-6, Keith Thompson wrote:
>> >> Even if we assume that that corresponds to `if (apple_count)`, what's
>> >> the corresponding English for if(node->next)?
>> >
>> > Since every pointer which is used in such a context is required to either
>> > be a valid pointer or a null pointer, the English would be "If the object
>> > pointed to by 'node' has a valid 'next' pointer, then...."  Although the
>> > code is in a literal sense comparing a pointer with a null pointer, such
>> > a comparison is merely the means by which code determines that a pointer is
>> > valid.
>> 
>> A null pointer is valid in some contexts (including this one), there are
>> invalid pointers other than the null pointer, and claiming that
>> 
>>     if(node->next)
>> 
>> can be read as
>> 
>>     If the object pointed to by 'node' has a valid 'next' pointer,
>>     then....
>> 
>> hardly supports the claim that it "reads like English".
>
> I should have said "every pointer is either a valid pointer *to an object*
> or a null pointer" but the principle holds.  So if you prefer, the test
> is for whether field "next" points to any object, as distinct from testing
> whether field "next" holds the only value it could hold without pointing
> to an object.

Of course node->next could also point just past the end of some array
object.

The claim was that `if(node->next)` "reads like English".  Do you
think it does, given the number of iterations we've gone through
to get an correct English description that's several times as long
as the code?  I don't, though it reads perfectly well as C (even
if it's not an idiom that I'd choose to use myself).

-- 
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]

#101866 — Re: Using == operator

Keith Thompson <kst-u@mib.org> writes:

> [who thinks `if(node->next)` "reads like English"]
>
> I don't, though it reads perfectly well as C (even
> if it's not an idiom that I'd choose to use myself).

I wouldn't call constructs like 'if(p)' or 'if(node->next)'
idioms.  These phrases show basic elements that were designed into
the C language deliberately, not a peculiar or surprising speech
form whose meaning is in any sense surprising or unpredictable.  A
phrase like "raining cats and dogs" is an idiom.  A sentence like
"See Spot run" or "Run, Spot, run" is not an idiom.

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

#101081 — Re: Using == operator

supercat@casperkitty.com wrote:

> On Tuesday, January 3, 2017 at 4:06:27 PM UTC-6, Keith Thompson wrote:
> > Even if we assume that that corresponds to `if (apple_count)`, what's
> > the corresponding English for if(node->next)?
> 
> Since every pointer which is used in such a context is required to either
> be a valid pointer or a null pointer, the English would be "If the object
> pointed to by 'node' has a valid 'next' pointer, then...."  Although the
> code is in a literal sense comparing a pointer with a null pointer, such
> a comparison is merely the means by which code determines that a pointer is
> valid.

Yes, that's the reasonable way any halfway experienced programmer will
read it. But it's not the _immediate English_ reading of the line.

Pretending that programming languages should be legible in the same way
that natural languages are is daft. Let's not pretend it is anything
else.

Richard

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

#101107 — Re: Using == operator

On Wed, 2017-01-04, Richard Bos wrote:
> supercat@casperkitty.com wrote:
>
>> On Tuesday, January 3, 2017 at 4:06:27 PM UTC-6, Keith Thompson wrote:
>> > Even if we assume that that corresponds to `if (apple_count)`, what's
>> > the corresponding English for if(node->next)?
>> 
>> Since every pointer which is used in such a context is required to either
>> be a valid pointer or a null pointer, the English would be "If the object
>> pointed to by 'node' has a valid 'next' pointer, then...."  Although the
>> code is in a literal sense comparing a pointer with a null pointer, such
>> a comparison is merely the means by which code determines that a pointer is
>> valid.
>
> Yes, that's the reasonable way any halfway experienced programmer will
> read it. But it's not the _immediate English_ reading of the line.
>
> Pretending that programming languages should be legible in the same way
> that natural languages are is daft. Let's not pretend it is anything
> else.

I assumed when you guys used the phrase "reads as English" you really
meant something like "reads fluently".  I.e. that it doesn't force you
to stop and think for a fraction of a second.

In some sense, I maintain that code should be readable like that
when possible.  If that makes me daft, so be it.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#101359 — Re: Using == operator

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

> On Wed, 2017-01-04, Richard Bos wrote:

> > Yes, that's the reasonable way any halfway experienced programmer will
> > read it. But it's not the _immediate English_ reading of the line.
> >
> > Pretending that programming languages should be legible in the same way
> > that natural languages are is daft. Let's not pretend it is anything
> > else.
> 
> I assumed when you guys used the phrase "reads as English" you really
> meant something like "reads fluently".  I.e. that it doesn't force you
> to stop and think for a fraction of a second.

Hm. I'm not a native speaker, either, but I'd have thought that if that
were the intent, it should be written "reads _like_ English", not "as
English".
I'm not sure that distinction can be made in German. It certainly can't
in Dutch. We write both of them as "als". Maybe in German you could
express one using "wie" and the other with "als", but I'm not at all
sure.

Richard

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

#101363 — Re: Using == operator

raltbos@xs4all.nl (Richard Bos) writes:

> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
>> On Wed, 2017-01-04, Richard Bos wrote:
>
>> > Yes, that's the reasonable way any halfway experienced programmer will
>> > read it. But it's not the _immediate English_ reading of the line.
>> >
>> > Pretending that programming languages should be legible in the same way
>> > that natural languages are is daft. Let's not pretend it is anything
>> > else.
>> 
>> I assumed when you guys used the phrase "reads as English" you really
>> meant something like "reads fluently".  I.e. that it doesn't force you
>> to stop and think for a fraction of a second.
>
> Hm. I'm not a native speaker, either, but I'd have thought that if that
> were the intent, it should be written "reads _like_ English", not "as
> English".
> I'm not sure that distinction can be made in German. It certainly can't
> in Dutch. We write both of them as "als". Maybe in German you could
> express one using "wie" and the other with "als", but I'm not at all
> sure.

Writing as a native speaker, I read his comment as meaning something
akin to "if you just read the notation using the most intuitive
vocalization".

There was nothing intuitive (to me) about reading that conditional as
English in the sense I just described.

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

#101849 — Re: Using == operator

raltbos@xs4all.nl (Richard Bos) writes:

> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
>> On Wed, 2017-01-04, Richard Bos wrote:
>>
>>> Yes, that's the reasonable way any halfway experienced programmer will
>>> read it.  But it's not the _immediate English_ reading of the line.
>>>
>>> Pretending that programming languages should be legible in the same way
>>> that natural languages are is daft.  Let's not pretend it is anything
>>> else.
>>
>> I assumed when you guys used the phrase "reads as English" you really
>> meant something like "reads fluently".  I.e. that it doesn't force you
>> to stop and think for a fraction of a second.
>
> Hm.  I'm not a native speaker, either, but I'd have thought that if that
> were the intent, it should be written "reads _like_ English", not "as
> English".

"As" is a tricky word.  One meaning of "as" is "in the same
manner or way that".  Depending on what is intended, the phrasing
"reads as English [reads]" may be appropriate.  (I offer no
opinion on whether this phrasing is a good correspondence for
"reads fluently" or the associated other description given for
that.)

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

#101856 — Re: Using == operator

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Wed, 2017-01-04, Richard Bos wrote:
>> supercat@casperkitty.com wrote:
>>
>>> On Tuesday, January 3, 2017 at 4:06:27 PM UTC-6, Keith Thompson wrote:
>>>> Even if we assume that that corresponds to `if (apple_count)`, what's
>>>> the corresponding English for if(node->next)?
>>>
>>> Since every pointer which is used in such a context is required to either
>>> be a valid pointer or a null pointer, the English would be "If the object
>>> pointed to by 'node' has a valid 'next' pointer, then...."  Although the
>>> code is in a literal sense comparing a pointer with a null pointer, such
>>> a comparison is merely the means by which code determines that a pointer is
>>> valid.
>>
>> Yes, that's the reasonable way any halfway experienced programmer will
>> read it.  But it's not the _immediate English_ reading of the line.
>>
>> Pretending that programming languages should be legible in the same way
>> that natural languages are is daft.  Let's not pretend it is anything
>> else.
>
> I assumed when you guys used the phrase "reads as English" you really
> meant something like "reads fluently".

The wording here is a little funny.  Usually "fluently" is used
to give an attribute to a reader, not to what is being read.
What I think you mean might be better expressed as "reads easily"
or "reads fluidly".

> I.e. that it doesn't force you
> to stop and think for a fraction of a second.

And indeed this re-wording matches what I just said.

> In some sense, I maintain that code should be readable like that
> when possible.  If that makes me daft, so be it.

I think most developers (or most sensible ones anyway) would
agree with that sentiment.  The question is, in what language
frame does the "read easily/fluidly" characteristic apply?  For
most low-level constructions, eg,

    if ( node->next ) ...

I don't "translate" them to an English description of what's
going on - it's faster and easier just to read the code directly.
In cases where it seems important to express some higher-level
conceptualization, normally I would use a procedural abstraction
such as the following (disclaimer: function name probably can be
improved):

    if ( more_elements_after(node) ) ...

Normally I would not do that for 'node->next' because it isn't
needed in such cases, but sometimes that depends on the context
where the if() statement appears - what works in one context
doesn't always work well in a different context.  And I expect
(albeit sometimes disappointedly) other developers to follow
similar precepts in their code.

Bottom line, I agree with your "reads fluidly" principle, but
what is fluid for one reader may be more viscous or even frozen
solid for a different reader.  Looking at what language frames
different readers expect may be a way of shedding some light on
why their perceptions differ.

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

#101034 — Re: Using == operator

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

> Also
>             if(node->next)
> 
> reads like English.

"If node minus is greater than next"!?

Code need not, and in this case should not, be read as English.

Richard

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

#101845 — Re: Using == operator

raltbos@xs4all.nl (Richard Bos) writes:

> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>
>> Also
>>             if(node->next)
>>
>> reads like English.
>
> "If node minus is greater than next"!?
>
> Code need not, and in this case should not, be read as English.

The discussion in this thread has brought out some interesting
points.  The comment here is one, and deserves some elaboration.

I take "read as English" in the quoted sentence to mean "read as
though phrased or re-phrased in natural language".  In effect the
"pro" side is saying code should be "translated" into English (or
perhaps some other natural language) and then understood as one
understands normal written English.  Richard's reaction (which I
agree with) dissents from this view:  if I may paraphrase, "maybe
sometimes, but not always, and certainly not here."

I join the dissent for two reasons.  One, the "translation" step
is an extra mental effort, which (often) slows down the process.
Two, and more significantly, natural language is almost always
more fuzzy semantically than the formal construction it would be
replacing.  In some cases it can be helpful to convey an
approximate rendition of what's going on, to aid comprehension.
At low levels though having to go through such re-phrasings is
usually more hindrance than help - it's better to understand the
formal construction directly, without having to shift language
frames.

A key skill in good programming is a refined judgment as to which
elements of a program benefit from a more "natural" depiction.
Some do, others do not.

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

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

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

csiph-web