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.

[E. Robert Tisdale]

Mike Malone wrote:

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

#define BEGIN {
#define END }
#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.

Why don't you use a sed script to modify some of your code
and see how you like it?

It takes a while to get used to it
and you will be obliged to invest some time
to adjust your tools to work with it
but, in the end, you will find that
people can get used to just about anything
and that they actually become quite fond of these things.

But, generally, I don't think that it's a good idea
to clutter up your macro namespace unnecessarily.
I believe that "coding style enforcement"
is a source of mischief and such issues
should be left up to the individual programmer.

[Ben Pfaff]

"Mike Malone" <mr*@prodigy.ne t> writes:

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 ==

The third is similar to the equivalents given in iso646.h:

and &&
and_eq &=
bitand &
bitor |
compl ~
not !
not_eq !=
or ||
or_eq |=
xor ^
xor_eq ^=

I don't know whether that's an argument for or against.
--
Just another C hacker.

[James D. Veale]

Pro - fewer nesting errors...

"Mike Malone" <mr*@prodigy.ne t> writes:

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.

[Keith Thompson]

"Mike Malone" <mr*@prodigy.ne t> writes:

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?

[...]

There are no good reasons to do this.

--
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.

[Peter Hickman]

Many moons ago someone suggested just this, it was called 'Easy C' and it turned
C into a weird form of Pascal, there were macros and even a small preprocessor.
There were several problems:

1) C programmers had difficulty reading the code
2) Pascal programmers kept thinking it was Pascal
3) People who learnt Easy C had to relearn C when the trainer wheels were removed

The big problem for C programmers is that programs became verbose without saying
more.

#define IF if(
#define THEN )
#define BEGIN {
#define END }
#define eq ==

converts this:

if(x == 1) {
puts("The value is 1");
}

into this:

IF x eq 1 THEN
BEGIN
puts("The value is 1");
END

They will produce the same output but the punctuation now takes up much more space.

[KiLVaiDeN]

"Mike Malone" <mr*@prodigy.ne t> a écrit dans le message de
news:dY******** **********@news svr19.news.prod igy.com...

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.

One thing that could be done to make more readable code, instead of
modifying original C syntax, would be to use conventions of identation and
comments.
That helps A LOT MORE than those kind of tricks, in my opinion.

K

[dandelion]

"Peter Hickman" <pe***@semantic o.com> wrote in message
news:41******** *************** @news.easynet.c o.uk...

Many moons ago someone suggested just this, it was called 'Easy C' and it turned C into a weird form of Pascal, there were macros and even a small preprocessor. There were several problems:

1) C programmers had difficulty reading the code
2) Pascal programmers kept thinking it was Pascal
3) People who learnt Easy C had to relearn C when the trainer wheels were removed
The big problem for C programmers is that programs became verbose without saying more.

#define IF if(
#define THEN )
#define BEGIN {
#define END }
#define eq ==

converts this:

if(x == 1) {
puts("The value is 1");
}

into this:

IF x eq 1 THEN
BEGIN
puts("The value is 1");
END

They will produce the same output but the punctuation now takes up much

more space.

And clutters up the view on the actual *payload*.

[Chris Croughton]

On Tue, 14 Dec 2004 03:18:33 GMT, Mike Malone
<mr*@prodigy.ne t> wrote:

A colleague of mine is proposing that we use a set of preprocessor
definitions to make our C code more readable:
How about your colleague learning C instead? Yes, it is possible to
write 'unreadable' C code, but that is possible with any language,
putting macros round constructs doesn't help.
#define BEGIN {
#define ENG }
#define EQ ==
etc.
I've seen it done. But why not counter-suggest that EQ is not
'readable' and it should be EQUALS, NOT_EQUALS, GREATER_THAN etc.?
Don't forget INTEGER instead of int, CHARACTER instead of char, PLUS and
MINUS, INCREMENT and DECREMENT...

You could make the language 'readable' as English like that, and also
increase your source code size by an order of magnitude, thus pleasing
management who will think you are working harder...
My initial reaction is "Yuck!" (Not too different from the FAQ, which just
says "Bleah").
Mine as well.
Aside from that, what are some good reasons to do this, or not to do this?
A few negatives I come up with include:
I can't see any good reasons to do it. If you want to program in Pascal
or Fortran, get a compiler for the language you like.
* Won't work with some tools, such as
- syntax-aware editors
- metrics
- static analysis tools
- coding style enforcement
- code indenters/reformatters
- pretty printers
Syntax-aware editors alone are a big reason to not do it, they often
save a lot of time all by themselves (for instance automatically
indenting and highlighting -- or rather failing to highlight -- typos in
keywords while typing).
* Requires re-training of C developers who are used to standard C syntax.

And retraining of people who have learned with the odd syntax.

Don't forget source-level debuggers, which are often confused by macros.

Chris C

[CBFalconer]

dandelion wrote:

"Peter Hickman" <pe***@semantic o.com> wrote in message

Many moons ago someone suggested just this, it was called 'Easy C'
and it turned C into a weird form of Pascal, there were macros and
even a small preprocessor. There were several problems:

1) C programmers had difficulty reading the code
2) Pascal programmers kept thinking it was Pascal
3) People who learnt Easy C had to relearn C when the trainer
wheels were removed

The big problem for C programmers is that programs became verbose
without saying more.

#define IF if(
#define THEN )
#define BEGIN {
#define END }
#define eq ==

converts this:

if(x == 1) {
puts("The value is 1");
}

into this:

IF x eq 1 THEN
BEGIN
puts("The value is 1");
END

They will produce the same output but the punctuation now takes up much

more space.

And clutters up the view on the actual *payload*.

At least format the quasi-Pascal properly:

IF x eq 1 THEN BEGIN
puts("The value is 1"); END;

or better:

IF x eq 1 THEN puts("The value is 1");

which still is neither fish nor fowl, real Pascal being:

IF x = 1 THEN writeln('The value is 1');

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!