Re: Why the C programming language book was never updated past C89?

From	Keith Thompson <kst-u@mib.org>
Newsgroups	comp.lang.c
Subject	Re: Why the C programming language book was never updated past C89?
Date	2015-02-05 13:40 -0800
Organization	None to speak of
Message-ID	<lnh9v0kpf8.fsf@nuthaus.mib.org> (permalink)
References	(2 earlier) <maviu4$dht$1@dont-email.me> <mavqib$ah7$1@dont-email.me> <mavsi2$ibc$1@dont-email.me> <lnoap8kxf2.fsf@nuthaus.mib.org> <mb0gqs$e4i$1@dont-email.me>
Show all headers | View raw
Bartc <bc@freeuk.com> writes:
> On 05/02/2015 18:47, Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>>> 2) intermingled declarations and code - makes code easier to write, but
>>> harder to read. In my view, easy-to-read takes precedence.
>>
>> I disagree.  Mixing declarations and statements (the word "code" seems
>> ambiguous) makes it easier to move declarations closer to where they're
>> used, and to initialize objects with their declarations:
>>
>>      {
>>          int x = ...;
>>          /* do some computations that modify x */
>>          const int y = x * 2;
>>          /* code that uses y */
>>      }
>>
>> In C90, I could do the same thing by introducing a new scope:
>>
>>      {
>>          int x = ...;
>>          /* do some computations that modify x */
>>          {
>>              const int y = x * 2;
>>              /* code that uses y */
>>          }
>>      }
>>
>> The alternative is:
>>
>>      {
>>          int x = ...;
>>          int y;
>>          /* do some computations that modify x */
>>          y = x * 2;
>>          /* code that uses y */
>>      }
>>
>> but then it's difficult to tell at a glance that the assignment is the
>> only thing that sets the value of y.
>
> It only makes it harder to see that if it's the same y, or whether there 
> are half a dozen variables all called 'y'.

I don't see shadowing (declarations with the same name in inner and
outer scopes) as a big problem.  It *can* be a problem when it happens;
I just haven't seen it happen very often.  Any such probelms can be
addressed by following a coding convention that forbids shadowing.  gcc
has an option "-Wshadow" that warns about it; other compilers may have
similar options.

(I might use `i` in nested for loops if the bodies of the loops don't
use the value of `i`; more likely I'd use `i` and `j`.)

> Disadvantages of allowing declarations anywhere, and allowing the same 
> name to be used in different block scopes:
>
> * When encountering a variable name X, you have to scan backwards every 
> line from that point, to the start of the function, to look for the 
> nearest definition. [Instead of going straight to the start.]

For relatively small functions, that shouldn't be too much of a problem.

[...]

> * It's harder to see where the code actually starts. With declarations 
> followed by statements, it's usually obvious where the declarations end 
> and statements begin (if not you can so a sort of 'binary search'). 
> Instead you now have to start at the very beginning and scrutinise every 
> line.

The code starts after the opening `{`.

Oh, did you mean *statements*?  Declarations and statements are both
"code".  (Though the C standard does informally use "declarations and
code" in the foreword; I would have used "declarations and statements.)

My point is that declarations can contain executable code.  For example,
a variable can be initialized with an expression that might have side
effects.

> * Mixed declarations clutter the code. Once declarations are out of the 
> way, then algorithms are clearer with just the names.

> * If you need to think of another variable, you have to scan the whole 
> function to see if it's already been used. Then you have to decide 
> whether you need to use a different name because the scopes cross, or 
> can get away with using the same name.

If you're defining a new variable, you should have a pretty good idea of
what it should be called, based on what it means and how it's used.  I'm
skeptical that this is going to be much of a problem.  On the other
hand, choosing names for things can be difficult, but I'm not convinced
mixing declarations and statements makes it any worse.

> * If you want to copy and paste fragments of code from one part of a 
> function to another, you'd better make sure you take include the 
> declarations of any variables! Otherwise there might be nasty surprises.

Nasty surprises that will be caught very quickly when the compiler
prints an error message.

> * If you want to document all the variables in a function, now it's a 
> much harder job because the declarations are disseminated through the 
> code with possibility of the same name used multiple times.

I'm not sure documenting all the variables in a function would be
useful.  I'd rather document sections of code.  In any case, unless your
functions are unreasonably long, mixing declarations and statements
isn't going to be a huge problem; the declarations still aren't that
difficult to find.

> * (More of technical objection but I'm uneasy with the idea of having a 
> name which is hard to pin down. If I want to talk about variable X in 
> function F, I now have to specify exactly which block of F it's defined 
> in, especially if there are several Xs; how do I do that?)

By not defining multiple variables with the same name in the same
function.


> I can go on but you should get the idea.
>
> Many of the objections can be overcome if multiple versions of the same 
> name aren't allowed, so that there is only one 'X' in the function for 
> example. But AFAIK I know the same name can be reused in different 
> scopes, so people will make use of that either deliberately or 
> inadvertently.

And how does mixing declarations and statements make this worse?  It's
always been possible to have declarations in inner blocks.  The change
in C99 just makes it possible to add new declarations without creating a
new block.

> Actually, given that people are always suggesting to keep functions 
> small, you have to wonder why it is necessary to declare a name right 
> next to it's first use instead of at the beginning of the function a 
> mere dozen lines away, if that.

It's not *necessary*, but as I wrote upthread it can be handy to define
a variable close to its first use, and to initialize it with a value
that might depend on previous computations.

-- 
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"
Thread

csiph-web