Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!lll-crg!caip!brl-adm!brl-smoke!smoke!gwyn@BRL.ARPA
From: gwyn@BRL.ARPA
Newsgroups: net.lang.c
Subject: Re:  printf() code size using Astartup.obj and AMIGA.LIB only
Message-ID: <2112@brl-smoke.ARPA>
Date: Fri, 11-Jul-86 07:39:42 EDT
Article-I.D.: brl-smok.2112
Posted: Fri Jul 11 07:39:42 1986
Date-Received: Fri, 11-Jul-86 23:06:49 EDT
Sender: news@brl-smoke.ARPA
Lines: 35

In agreement with Guy and others, I do not equate readability of C
code with use of the minimum number of tokens.  Readability pertains
to the human mind, perceptions, cognitive psychology, etc. which
makes it hard to reduce C code readability to a simple set of rules
for construction.  However, there are several known good principles
(data abstraction, modularity, good mnemonics, and so forth).  The
key point is that readability depends on conceptual clarity.  This is
why, as Guy points out, it is proper to maintain a conceptual
distinction between Boolean data and pointers, even though C itself
permits blurring of such distinctions.  The use of NULL to mean
"invalid pointer, no data can be accessed via this pointer" is one
important tool for writing intelligible code.  I probably once
thought that it was neat that C (like B, which I never used) folded
together a lot of apparently separate things; fortunately if I did
think that I have since come to my senses.  Simply combining
entities is a far cry from integrating them into a cohesive
concept.  [loose use of terms here so I can be understood by non-
epistemologists]  The only "concept" served by ignoring data types is
that of the machine storage cell (just like B), which is the wrong way
to go, since leverage is obtained by extending one's focus to higher-
level abstractions, not lower.  Only when there is a real need to
be concerned with low-level details (e.g. when writing device
drivers) should one stoop to working at that level of abstraction.

Incidentally, ANSI X3J11 seems to be urging the general adoption of
	(void *)0
as the definition of NULL instead of the
	0
that Guy and I agree is the best definition.  I don't know what
their rationale for that is.  It may be meant to help compensate
for lack of care commonly seen in code such as:
	func( arg1, arg2, NULL, arg4 );
since on lucky machines where all pointers happen to be the same
size, that would work despite the fact that it was coded wrong.
I think that's a bogus reason, if it is indeed the reason.