🚀 go-pugleaf

In article <cg.0afn@ami-cg.UUCP> cg@ami-cg.UUCP (Chris Gray) writes:
>In article <1992Jul22.000454.24871@ccu1.aukuni.ac.nz> stuartw@ccu1.aukuni.ac.nz
>writes:
>>	base_ptr[offset]=value;
>>
>>	or
>>
>>	*base_ptr+offset=value;
>
>He he! I just love it when someone saying how great C is messes up with a
>common C error! The above two are of course not equivalent - extra parentheses
>are needed around the 'base_ptr+offset' in the second form.
>
>I've been skipping through these articles on 'TP or C', not realizing I've
>been missing the glorious fun of putting C down!

May I point out that you're not putting down C, you're putting down a
PERSON who *uses* C.

>C is one of the unfriendliest languages I've come in contact with, especially
>in the ways it is used by far too many people.

You know, I always suspected that most of the C bashers in the world
hate the language because they aren't posessed of the intellectual
capacity to understand how to use it. People who think a for loop in C
is confusing, for example. Based on your experience in writing an ANSI C
compiler, I see that you are an exception to this rule. ;-)

Personally, I'd rather be "confused" by a C for loop than be genuinely
confused at all the bizarre dialects that call themselves Pascal. I can
port a Borland C program to Unix C or VAX C or even Atari 8-bit C with
little trouble. The same can *not* be said of a Turbo Pascal program!

Face it, ugly spaghetti code can be written in ANY language. Don't try
to blame the language for a lack of skill on the part of the programmer.

>Folks! Use full prototypes. Turn on all possible warning flags. Make your
>code compile clean. Use some fairly standard programming style. Make your
>file global variables instantly distinguishable from your local ones. Avoid
>inter-file globals (externs) like the plague. Don't overuse macros. Make
>ALL macro names in all upper case (except perhaps true/false).
>
>Anyone (including yourself after a few years) who has to work with your code
>will greatly thank you.

Agreed 100% - and don't forget *thorough* internal documentation! At the
very least, the header comments for a function should identify all
parameters and explain their use. Local variables should also have a
brief comment next to their declarations. Finally, each block of code
within the function should have its own small comment block.

Looks like we're well on our way to writing a Usenet Manual of C Form
and Style. ;-)