more about programming style

[Mike Shaddock]

In article <11457 at brl-tgr.ARPA> DHowell.ES at Xerox.ARPA writes:
>Ok, let me clarify a few things here.  By "idioms", I mean a piece of
>code in a language which can be directly translated into another piece
>scenario.
> ... (Some stuff here)
>wanted.  Therefore I must look at the code ("Foul", I hear you say.
>"What are you doing looking at his code; you're not an experienced C
>programmer!"  Well who else can look at it, if the programmer can't fix
>it himself?  At least I know what I want done).  The program turns out
> ... (Some more stuff).

I don't know about you, but I don't jump into programs written in a
language that I don't know without first either learning a little about
the language or having someone help me through the program.  Anyone who
took ten minutes to learn something about C would know what "stuff++"
did, and wouldn't ignore it.  As for the comments (not made by DHowell,
I'm just concatenating followups) about experienced C programmers, how
many people put non-experienced C programmers on a big project?  If
they don't know a language, they shouldn't be mucking with the code!
This applies to any language, not just C.  Most of the common "idioms"
(((fp = fopen()) == ERR), i++) are not that hard to understand.  This
doesn't mean that I advocate using every trick in the book, I'm just
saying that using the "idioms" of a language is not so bad.
-- 
Mike Shaddock			{decvax,seismo}!mcnc!rti-sel!shaddock