PROS/CONS: #define BEGIN {

M

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

E. Robert Tisdale

Mike said:
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.
 
B

Ben Pfaff

Mike Malone said:
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.
 
J

James D. Veale

Pro - fewer nesting errors...

Mike Malone said:
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").
 
K

Keith Thompson

Mike Malone said:
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.
 
P

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

KiLVaiDeN

Mike Malone said:
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
 
D

dandelion

Peter Hickman said:
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*.
 
C

Chris Croughton

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
 
C

CBFalconer

dandelion said:
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');
 
D

Dan Pop

In said:
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?

ANY usage of the C preprocessor that messes with the language syntax
should be avoided, unless the redeeming benefits are great enough to
compensate for the loss in program readability. And this kind of silly
substitutions have exactly zilch redeeming benefits.

Apparently, the original implementation of the Bourne shell was made
using a header file named "algol.h", whose purpose should be obvious
from its name. The end result was that no one wanted to maintain that
program, so it had to be retranslated to proper C.

Dan
 
B

Bart

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.


Proper English words are in my opinion more readable than lots of
punctuation, even if it takes more space, and C does seem to have far
too many unnecessary symbols, such as semicolons.

The C syntax looks like something that was hastily knocked up one
afternoon and nobody has updated it since.

However that *is* the C language and most seem happy with it.

Tinkering with bits of syntax using DEFINEs is likely to be
unsatisfactory; the above example seems a mix of FORTRAN, PASCAL and
C.

Either use a different language or a formal language extension that
uses software to convert your favorite syntax into standard C (my pet
project).

Bart.
 
K

KiLVaiDeN

Proper English words are in my opinion more readable than lots of
punctuation, even if it takes more space, and C does seem to have far
too many unnecessary symbols, such as semicolons.

I think it'd be very annoying after a while to see tons of "BEGIN"
everywhere on the code..

Imagine something like ( useless code ) :

while(true)
{
do_something();
if(something is true)
{
do_something_else();
increment_something();
}
else
{
decrement_something();
do_nothing();
}
}

Would translate into something like :

while(true)
BEGIN
do_something();
if(something is true)
BEGIN
do_something_else();
increment_something();
END
else
BEGIN
decrement_something();
do_nothing();
END
END

Really the first one looks more readable to me !

One good thing with the punctuation, is that you can see the idents
associated with them easily, and if you need additionnal information, put
comments like :

while() {

} // end while @ line 258

K
 
E

E. Robert Tisdale

Bart said:
Proper English words are, in my opinion,
more readable than lots of punctuation,
even if it takes more space
and C does seem to have far too many unnecessary symbols,
such as semicolons.

The C syntax looks like something
that was hastily knocked up one afternoon
and nobody has updated it since.

It certainly was *not*.
It was very carefully crafted
to take advantage of the ASCII character set
and to minimize the number of keystrokes
which you would realize was a very important consideration
if you had ever tried to program at a teletype terminal.
However that *is* the C language and most seem happy with it.

Tinkering with bits of syntax using DEFINEs
is likely to be unsatisfactory;
the above example seems a mix of FORTRAN, PASCAL and C.

Either use a different language
or a formal language extension that uses software
to convert your favorite syntax into standard C (my pet project).

I agree that the C preprocessor
is a poor language translation tool.
 
C

Christian Bau

"Mike Malone said:
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.

It would have better if he had made this proposal during his job
interview. That way, no time would have been wasted by hiring him.
 
B

Bart

...

I think it'd be very annoying after a while to see tons of "BEGIN"
everywhere on the code..

Imagine something like ( useless code ) :

while(true)
{
do_something();
if(something is true)
{
do_something_else();
increment_something();
}
else
{
decrement_something();
do_nothing();
}
}

Would translate into something like :

while(true)
BEGIN
do_something();
if(something is true)
BEGIN
do_something_else();
increment_something();
END
else
BEGIN
decrement_something();
do_nothing();
END
END

Really the first one looks more readable to me !


I admit I'm not a fan of 'begin', I would code your fragment as
something like (loosely taken from Algol68):

do
do_something
if something then
do_something_else
increment_something
else
decrement_something
do_nothing
endif
end

The original C has:

5 extra semicolons (perhaps one more after final } needed?)
5 extra lots of () for functions
1 () pair for the 'if'
2 extra {, the other replaced by 'then'
1 extra } just before 'else', the others replaced by 'endif'/'end'
1 () pair around 'true' ('while true' is redundant, 'do' will start an
endless loop)

As I said in my original post, lots of unnecessary punctuation in C,
perhaps 20 symbols in this short fragment, without which the code
looks much cleaner, especially printed with bold keywords.

As for extra typing, the original C source had some 177 bytes, my code
about 143 bytes (without 'while true'), and with endif/end removed,
python-like, as they could be made redundant, would be about 130 bytes
(all using tabs not spaces).

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

dandelion

5 extra semicolons (perhaps one more after final } needed?)
5 extra lots of () for functions
1 () pair for the 'if'
2 extra {, the other replaced by 'then'
1 extra } just before 'else', the others replaced by 'endif'/'end'
1 () pair around 'true' ('while true' is redundant, 'do' will start an
endless loop)

You seem to be of the opinion that the "extra" punctuation is a bad point.
I, for one, do not think of it as such.

For instance, the language you use omits '(' and ')' for function names, but
i do not suppose that this is also the case when you want to apply a few
parameters. Furthermore, in 'C'

int foobar(void);

int some_var = foobar();

is something completely different than

int foobar(void);

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 "unnecessary".
As I said in my original post, lots of unnecessary punctuation in C,
perhaps 20 symbols in this short fragment, without which the code
looks much cleaner, especially printed with bold keywords.

Ah... A matter of taste. Well, tastes differ.
As for extra typing, the original C source had some 177 bytes, my code
about 143 bytes (without 'while true'), and with endif/end removed,
python-like, as they could be made redundant, would be about 130 bytes
(all using tabs not spaces).

Using tabs do to indenting is a *very* bad idea. I've seen more source that
looked like garbage (but wasn't) due to this. As an aside, i could not care
less about a few extra bytes of *source* code. A few extra bytes of *object*
code may keep me awake at night, though.
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.

Well, at least you did not convince me.
 
L

Lawrence Kirby

Proper English words are in my opinion more readable than lots of
punctuation, even if it takes more space, and C does seem to have far
too many unnecessary symbols, such as semicolons.

Where are C's semicolons unnecessary? Even Pascal uses them in a similar
way. The main difference in (imperative) languages are those that treat
end of line as a terminator. This has its own drawbacks and later
(imperative) languages tend to avoid it. If you don't do that you need
something to act as a separator/terminator.
The C syntax looks like something that was hastily knocked up one
afternoon and nobody has updated it since.

Well I might agree with you on that concerning the switch statement. :)
However that *is* the C language and most seem happy with it.

We do recognise that there are things that could be designed better in C,
like operator precedence and integral promotions. Many people bemoan
declaration syntax. But the basic syntax and symbology of statements and
operators works pretty well, and it is hard to find anything that doesn't
serve a purpose. E.g. consider

if (isupper(ch)) *p = ch;

Take those ()'s for the if away and you get

if isupper(ch)*p = ch;

which isn't the same thing, or would be hard to parse consistently as the
same thing in the general case.

Lawrence
 
B

Bart

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

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

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.

....
Ah... A matter of taste. Well, tastes differ.

Yes, of course. The OP's colleague presumably had migrated from PASCAL
or wherever and couldn't cope with all the {,} in C (I think in
PASCAL these are comment symbols!).

It is highly unlikely ISO C will change it's syntax for my benefit or
for others (although syntax is so easy to change), so I guess I will
soon have to be writing raw C as well.

Bart
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top