Re: Code Comprehension

Pascal Bourguignon wrote:

When you have characters, use '\0' which explictely says Hello! I'm a
character.

Not really following on from that, but this is a convenient point to
raise an issue which interests me, and which we seem to be skirting
around without ever quite touching explicitly.

Given a language like C, where the actual semantics differ quite
considerably from what I would describe (with no offense intended) as
"what a PASCAL programmer would expect"[*] and further assuming that
the programmer is intent on making the program text as clear and
readable as possible (not necessarily compatible aims), what is the
best way to use that language's semantics ?

It seems to me that there are two options, or at least two ends to a
spectrum. At one end, you can program to the languages /actual/
semantics, expecting the reader to understand the language itself (not
some idealised approximation), and making use of idioms which depend on
that. At the other end, you can constuct a subset of the language
(which approximates as closely as you can manage to the "ideal"
version), and then stick rigidly to programming in that subset.

For example, in C, the value tested by an "if (...)" is not a boolean
-- the semantics of "if" (in C) neither require nor expect a boolean
value. So you can (at one end of the spectum) write:
char *s = ....
if (s)
or:
if (*s)
or even:
if (s && *s)
and you will be using the actual semantics of the language. OTOH, you
can "pretend" that if and && only work on booleans and rephrase the
above as:
if (s != NULL)
if (*s != '\0')
if (s != NULL && *s != '\0')

On the face of it, one would expect the latter always to be preferable
-- after all, code which says what it means is better than code which
only implies what it means. But does that work in general ? I think
that Pascale thinks it does. But then there's a problem: I found
Pascal's recoding of the OPs problem to be completely obscure, /vastly/
less readable (in fact incomprehensible) than Rob's more idiomatic
rephrasing of the program as "real" C.

It is my no means obvious that it is a good thing to "pretend" that a
language's semantics are other than they are. My opinion is that it
is bad -- if nothing else it gives the reader two levels of semantics
to think about: what does the program actually mean (given the real
semantics) and what does the writer /think/ it means (using whatever,
uspecified, semantics s/he has invented as an "ideal").

Another downside of the "idealised" approach is that it risks
forbidding (some) idiomatic use of the language. As in the running
example, it would not allow:
if (!a || !b)
return;
but would insist on a more verbose re-writing. So the question is:
does that help comprehension ? In my experience, the answer is
typically "no". It is true that there can be idioms which lend
themselve to misinterpretation, but they tend to be rare -- idioms
become idioms because (considered as memes) they are /sucessful/. And
one good strategy for a would-be-successful idiom is to help make the
code readable (not to say that there aren't other strategies available,
such as making the programmer feel cool, etc).

Another, much more practical, point is that sticking to the "idealised
approximiation" is not a good idea if you are going to have to work
with code from people who don't use that subset -- you won't have as
much practise reading or writing code in that "style", and it will make
your life unecessarily difficult.

Well, that's my opinion, anyway...

But my real point is that this issue is one that should be /explicit/.
We shouldn't base our ideas of what is good on unexamined assumptions
about how to make best use of the language -- these matters are not
obvious, and any position based on "well /of course/ its better to do
xxx" is likely to be wrong, unless it has some actual thought behind it.

-- chris

[*] I've put "Pascal", incorrectly, into upper case to emphasise that
I'm not talking about Pascal Bourguignon -- the complexities of Usenet
communication... sigh....
.

Relevant Pages

  • Re: Code Comprehension
    ... Given a language like C, where the actual semantics differ quite ... It is true that there can be idioms which lend ... There are C idioms that *improve* readability? ...
    (comp.programming)
  • Re: object system...
    ... conflict with the actual sun and stars (so, ... Interface too can have some properties defined in terms of third types ... not the language or its target. ... If you ignore overflow exceptions, then necessary, the semantics becomes ...
    (comp.object)
  • Re: Code Comprehension
    ... Given a language like C, where the actual semantics differ quite ... you because of your level of familiarity. ... producing correct code and other sets of semantics that don't. ...
    (comp.programming)
  • Re: what follows from denying an axiom
    ... Chris Menzel is the first person I have ever heard say "second-order ... language purely syntactically. ... Formal system has no semantics. ... to the resultant perception-phenomenon known as relativity, ...
    (sci.logic)
  • Re: what follows from denying an axiom
    ... language purely syntactically. ... Formal system has no semantics. ... to the resultant perception-phenomenon known as relativity, ... Provability is thus relative to a proof theory, ...
    (sci.logic)