C's syntax (was Re: Python Formatted C Converter (PfCC))

Makhno mak at imakhno.freeserve.co.uk
Mon Oct 23 07:57:54 EDT 2000


>Even from a human-factors point of view, such syntactic
>tripwires (over which people DO keep stumbling...) as
>    if(a=0) ...       /* oops, an assignment...! */

Most compilers warn at this point and make you write if ((a=0)) ...

>or
>    foo* bar, baz;    /* NOT two pointers... */

I prefer to write my pointer declarations like this

foo *bar;

then there's less confusion. To my mind it's as though I'm writing

foo [*bar];

ie: [*bar] is a foo, which is correct.

It then follows that you can easily write

foo *bar,baz;

One pointer to a bar, one whole baz.

>or
>    struct foo {
>        int bar;
>    }    /* forgot a semicolon... */
>    /* int can be omitted and is implied -- how CRAZY! */
>    myfun() ...

Are you complaining about the implicit 'int' for function, or that if you
forget the semicolon after the struct declaration and then try to declare
the function afterwards the compiler will assume the the function returns
the struct? Implicit 'int' functions are old anyway, modern compilers should
warn.

>hardly combine to make C's syntax "pretty good".  TERRIBLE
>is more like it.

Oh please calm down. C's syntax has something to do with its success eg: Not
having to write code at the speed of the slowest person. I personally don't
care if some newbie writes 'if (a=0)...' when they mean 'if (a==0)' because
I don't. Anyway, they should be writing 'if (!a) ...'
I like being able to compress less-important mundane error checking code
into a couple of lines, saving the long winded approach to more complicated
parts, where readability is important.

>:-)

phew. A smiley. Was worried for a moment that you were serious.






More information about the Python-list mailing list