PROS/CONS: #define BEGIN {

[Mike Malone]

A colleague of mine is proposing that we use a set of preprocessor
definitions to make our C code more readable:

#define BEGIN {
#define ENG }
#define EQ ==
etc.

My initial reaction is "Yuck!" (Not too different from the FAQ, which just
says "Bleah").

Aside from that, what are some good reasons to do this, or not to do this?
A few negatives I come up with include:

* Won't work with some tools, such as
- syntax-aware editors
- metrics
- static analysis tools
- coding style enforcement
- code indenters/reformatters
- pretty printers

* Does not check for mismatches (e.g., "{" vs. "END").

* Does not prevent use of {, }, ==, etc., just adds alternatives.

* Requires re-training of C developers who are used to standard C syntax.

[Chris Croughton]

On Wed, 15 Dec 2004 14:27:41 +0000, Bart
<48**@freeuk.co m> wrote:

You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line.
In real code a lot of statements take more than a line (at least with
reasonable line lengths). Typing semicolon is one character per
statement, having to add \ at the end of lines (and take them out) or
some other continuation character is a lot more painful. As is typing
BEGIN and END (and THEN and ENDIF for statements which don't need them).
I
must spend half my time playing pendantics with my compiler instead of
developing my application.
Then you should learn to write C. I very rarely have a semicolon
missing from a statement when I program in C. Yes, it's annoying when
the compiler flags some silly error, but it's a lot more expensive if it
just assumes that you meant whatever it was
It is highly unlikely ISO C will change it's syntax for my benefit or
for others (although syntax is so easy to change),
Syntax is not at all easy to change. Have you ever written a compiler?
Would you like to have to change millions of lines of existing code
because someone wants to change the syntax (and debug it, and verify
it...)?
so I guess I will
soon have to be writing raw C as well.

Indeed. Or you could get Visual Basic...

Chris C

[Lawrence Kirby]

On Wed, 15 Dec 2004 14:27:41 +0000, Bart wrote:

On Wed, 15 Dec 2004 12:46:56 +0100, "dandelion" <da*******@mead ow.net>
wrote:

int some_var = foobar(); ...

some_var = foobar;

This difference does not seem to be translated into your language. It also
shows that at least some of the parenthesis aren't "unnecessar y".

some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&fooba r.

Yes, you could do that. However when I see

some_var = foobar();

I know that foobar() is a function call. When I see

some_var = foobar;

that wouldn't be obvious at all. Having used languages like Pascal (indeed
before I started using C) it is my considered opinion that C's approach is
simply better in this respect.
You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line. I
must spend half my time playing pendantics with my compiler instead of
developing my application.

I haven't found typing one extra character per line a great hardship. The
more significant question is whether this syntax aids readability, which
is harder to say. Most languages I've used that don't do this have been
text processing or scripting languages and comparing readability between
such different languages, and how much of that is down to ; isn't easy. I
think code using ; is more consistent, especially in languages that try to
"guess" whether a 2nd line is a continuation or a new statement/command.

Lawrence

[john_bode]

Bart wrote:

Of course I'm not expecting to persuade anyone reading comp.lang.c
that C syntax is anything other than wonderful... just a few
observations.

Bart.

It's not that C syntax is so wonderful (it really, really isn't); it's
that using the preprocessor to redefine the language *always* leads to
heartburn. The OP's negative points are spot on. It breaks
language-sensitive tools; it requires retraining; it will lead to
maintenance headaches as the language changes over time.

If you don't like C syntax, USE A DIFFERENT LANGUAGE. There are plenty
to choose from.

[Keith Thompson]

"dandelion" <da*******@mead ow.net> writes:

"Bart" <48**@freeuk.co m> wrote in message
news:9q******** *************** *********@4ax.c om... [...]

some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&fooba r.

That would give me a pointer-to-a-pointer-to-a-function.

http://www.eskimo.com/~scs/C-faq/q1.34.html

No, it doesn't (and the FAQ doesn't say it does). A function name in
an expression decays to a pointer-to-function *unless* it's the
operand of "&" or "sizeof" (the latter case is a constraint
violation).

You must admit C does have an awful lot of semicolons: perhaps 90% or
more associated with end-of-line (EOL) yet typing EOL is not enough, I
must also type ;, because a few statements take more than one line.

And I can have as many statements on a line as I wan't to. Not that
I generally do that, but we *are* talking about 'C', which allows
it. Hence the semicolon.

If C banned multiple statements per line, it would be no great loss in
my opinion (except, of course, that it would break tons of existing
code). The real issue is multi-line statements. Most C programmers,
I think, type the trailing ';' without thinking about it, and barely
notice it when reading code.
Besides, 'end of line' is code '0x0A' on some systems, '0x0A, 0x0D'
on others and a third variety does it using '0x0D'. Using your
preference, a (say) Unix source cannot compile on a (say) Macintosh
and neither will compile on a Windblows machine.
Irrelevant. Any source file has to be converted when it's transferred
from one system to another. Some compilers may tolerate, e.g., CR-LF
pairs on a Unix system, or LF line terminators on a Windows system,
but in general if the text file formats differ you have to translate.
And to top the bill, I like to leave white-lines between blocks of code to
improve readability. I frequently chop up looooooooong calls into separate
lines for the same reason, and do the same with lenngthy versions of
conditions in if(), while() and friend. Those extra newlines (excusez le
mot) would be part of the language in your setup.

I would not like that. And that's putting it (very) mildly.

If a C-like language used end-of-line rather than semicolon to delimit
statements and declarations, presumably it would be designed to permit
arbitrary blank lines. (I think Python does this.)

[snip]

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Bart]

On 15 Dec 2004 14:08:53 -0800, jo*******@my-deja.com wrote:

If you don't like C syntax, USE A DIFFERENT LANGUAGE. There are plenty
to choose from.

Not so many. Some people like the low-level, machine-oriented
semantics of C, where you can usually double-guess what the compiler
will do, but are not so keen on the look and feel. And other
considerations may require the use of C.

Perhaps the syntax of a language should be separate from the rest of
it, like a 'skin' that can be chosen according to preference. That
would be something..

Bart

[dandelion]

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

<snip>

And to top the bill, I like to leave white-lines between blocks of code to improve readability. I frequently chop up looooooooong calls into separate lines for the same reason, and do the same with lenngthy versions of
conditions in if(), while() and friend. Those extra newlines (excusez le
mot) would be part of the language in your setup.

I would not like that. And that's putting it (very) mildly.

If a C-like language used end-of-line rather than semicolon to delimit
statements and declarations, presumably it would be designed to permit
arbitrary blank lines. (I think Python does this.)

That does not address the point of breaking up long statements into multiple
lines for readability.

<snip>

[dandelion]

"Bart" <48**@freeuk.co m> wrote in message
news:b6******** *************** *********@4ax.c om...

On 15 Dec 2004 14:08:53 -0800, jo*******@my-deja.com wrote:

If you don't like C syntax, USE A DIFFERENT LANGUAGE. There are plenty
to choose from.

Not so many. Some people like the low-level, machine-oriented
semantics of C, where you can usually double-guess what the compiler
will do, but are not so keen on the look and feel. And other
considerations may require the use of C.

Perhaps the syntax of a language should be separate from the rest of
it, like a 'skin' that can be chosen according to preference. That
would be something..

Checkout http://gcc.gnu.org

You may not be the first with that idea.

[Keith Thompson]

"dandelion" <da*******@mead ow.net> writes:

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

<snip>

> And to top the bill, I like to leave white-lines between blocks
> of code to improve readability. I frequently chop up looooooooong
> calls into separate lines for the same reason, and do the same
> with lenngthy versions of conditions in if(), while() and
> friend. Those extra newlines (excusez le mot) would be part of
> the language in your setup.
>
> I would not like that. And that's putting it (very) mildly.

If a C-like language used end-of-line rather than semicolon to delimit
statements and declarations, presumably it would be designed to permit
arbitrary blank lines. (I think Python does this.)

That does not address the point of breaking up long statements into
multiple lines for readability.

No, it doesn't. Since I don't think it's a good idea, I wasn't going
to work out all the details.

But I suppose the most obvious thing to do would be to use '\' as a
continuation character.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

Lawrence Kirby <lk****@netacti ve.co.uk> wrote:

On Wed, 15 Dec 2004 14:27:41 +0000, Bart wrote:

some_var=foobar presumably takes the address of the function, which is
probably better written explicitly as some_var=&fooba r.

Yes, you could do that. However when I see

some_var = foobar();

I know that foobar() is a function call. When I see

some_var = foobar;

that wouldn't be obvious at all. Having used languages like Pascal (indeed
before I started using C) it is my considered opinion that C's approach is
simply better in this respect.

It's even worse in Pascal, because it does allow the name to occur, as a
normal identifier, on the left side of an assignment (where it
represents the return value); this makes it easy to assume, erroneously,
that it _is_ a normal identifier, and can be used on the right side as
well.

Richard

[Lawrence Kirby]

On Thu, 16 Dec 2004 10:47:08 +0000, Keith Thompson wrote:

....

But I suppose the most obvious thing to do would be to use '\' as a
continuation character.

You can do that, some languages do and even some data file formats. For
human edited data like source code it has IMO proved to be a VERY
error-prone mechanism.

Of course C has this mechanism which can be used anywhere but isn't needed
except for multi-line macro definitions and the old method of multi-line
string literals. IMO it is only the fact that the need to use it is rare
that makes it tolerable. It would be grim indeed if you had to use it for
every multi-line statement.

Lawrence