Re: Easily-Read C++?

[castori@litsun.epfl.ch (Pierre Castori)]

In article <941005030023_73672.2025_DHR103-1@CompuServe.COM>, Ken Garlington <73672.2025@COMPUSERVE.COM> writes:
   |> |> Robin Rowe <cpp@NETCOM.COM> writes:
   |> |>
   |> |> Before I begin, I want to make two things clear. One, that I intend 
   |> |> no disrespect to the author of the original paper, and two, that I 
   |> |> am an expert in C++ but not in Ada.  
   |> |>
   |> |> [lots of stuff deleted]
   |> |>
   |> |> << Here's how I read a piece of C++ code:
   |> |>
   |> |>    if(!object)                  // "If not object [then]"
   |> |>    {   cerr<<object.ErrorMsg(); // "output object's error
   |> |>    }                            //  message,"
   |> |>    else                         // "else"
   |> |>    {   object++;                // "increment object."
   |> |>    }
   |> |>
   |> |> So what's unnatural about this? Sounds like English to me. >>
   |> |>

Of course! Didn't you say you were a C++ expert? Would look weird if
you couldn't understand this easily don't you think so?  By the way,
what about the same code without the comments? ...

   |> Not that I'm a C++ expert, but I have noticed that a lot of C/C++ code looks
   |> like Greek to me. Certainly, that stuff on the right reads like English to me
   |> (is this normal C style to comment every line?) but the stuff on the left I
   |> have to think about a little. On the other hand:
   |> 
   |>    If Not(object) then
   |>       Text_IO.Put_Line (Error_Message (corresponding_to => object));
   |>    else
   |>       object := object + 1;
   |>    end if;
   |> 
   |> is easily read by _any_ engineer (never mind software engineer) on my project.
   |> (Of course, I would have to explain what the "not" of a numeric value is,
   |> maybe, but a more meaningful function name is probably a good idea in this
   |> case.) In fact, it looks suspiciously like the English explanation of the C
   |> code. Note that some of these engineers didn't take the math class where "++"
   |> means "add one to the thing before the ++." However, "X = X + 1" is something
   |> they got pretty early on. That colon hanging off the equal sign doesn't seem to
   |> bother them much.
   |> 

Totally agreed. I can't understand how people can honestly claim C or C++ are
as readable as Ada. More generally did you realize how often C/C++
programmers use abbreviations? They seem to implicitly admit that what they are
writing will be understood. And this seems to be automatic in the C community.
This probably comes from the times when people were taught C. You learn to use
good old int (integer), rd (read) and fd (file descriptor). Then it is natural
to continue using such abbreviations. What is the big deal in writing
file_descriptor?  Laziness?  Why cerr and Msg in the example above? 
Agreed that ErrorMsg is understandable. But again what is the problem in
writing Error_Message?  Especially with nowadays editors that have so many
features to help you complete words, indent automatically, etc.

Comparatively, Ada programmers seldom abbreviate. I am not saying they never
do it. I am saying the tendency in the Ada community is naturally not to
use abbreviations (ease of reading). While the tendency in the C community is
naturally to use abbreviations (ease of writing). The C/C++ languages themself are
designed with some sort of a compact-statements-do-a-lot principle.

Abbreviations make programs much more difficult to read and understand.
In writing programs, I think many programmers forget the well-known principle:
a program is written once, read many. And "many" means many other people than
the author!

   |> Has anyone tried a study like the following? Take some C++ code from Software
   |> Development, or Embedded Systems Programming, or whatever. Write the Ada 9X
   |> equivalent. Show the 9X code to C++ programmers who have never seen Ada, and
   |> the C++ code to Ada programmers who haven't worked with C recently. Which set
   |> of code would be understood more often?

Guess ... ;-)

In computer science papers that present some algorithms, it is seldom the case
that these algorithms are described in a C-like fashion. Most often, a Pascal-like
solution is used even when the algorithm is really implemented in C/C++. Howcome?
I thought C was THE widely accepted language. For me, this says it all.

//Pierre.

============================================================================
| Pierre Castori                           |      Tel : +41 21 693 2054    |
| Dept. of Computer Science                |      Fax : +41 21 693 4701    |
| Swiss Federal Institute of Technology    |-------------------------------|
| EPFL - IN ECUBLENS                 ______| Email: castori@litsun.epfl.ch |
| 1015 Lausanne (SWITZERLAND)       | http://litwww.epfl.ch/~castori/.html |
============================================================================