#define OR ||

[Tom Neff]

In article <1031 at carmine1.UUCP> yedinak at cell.mot.COM (Mark A. Yedinak) writes:
>There are several underlying issues within this discussion which should
>really be considered. First, if programmers would learn (that is TRULY
>learn) the languages they work in, there would be no need for this
>discussion. 

This seems to me to be less a matter of education than of belief.  In my
experience, programmers who substitute old familiar tokens for new ones
do KNOW the new language -- they have to in order to write the defines --
they just don't LIKE it.  They think the new way is "dumb" and the old
way was "better" or "just fine."  I have heard all sorts of irrational
justifications.  Only when they BELIEVE in the new language, by having
succumbed to its charms (or having been forced to use it on pain of
termination!) do they change their minds.

At a less obnoxious level than preprocessor defines, this occurs all the
time with algorithms and packages.  We are all familiar with the
"itinerant" systems or applications programmer who has "his libraries"
that go with him wherever he goes.  In the days when everyone programmed
FORTRAN this was a straight shot, but now that we live in Babel he often
spends his fifth through tenth weeks (never the first!) REWRITING his
libraries into whatever the new lingo is.  In a bustling shop full of
experienced primadonnas this can be quite an issue, as each new worker
arrives with his OWN way of "doing everything" and tosses it into the
pot.  Again, only when faced with the executioner's halberd will some of
these folks deign to use a FOREIGN package. :-)

>             Hence, the reason so much time was spent to develop a
>standard. With a standard everyone is talking the same language and
>there is not room for ambiguity in interpretation, as there will be if
>every developer uses the preprocessor to customize their source code.

Oops, I seem to be talking to myself.  The above is in left field, the
Standards have little to say about this phenomenon.  The original poster
wanted to do something PERFECTLY legal within the ANS document.  What
was interesting and discussible about it was that it's lousy programming
practice, even if permitted by the standard.

>Also, if more developers would spend time designing their code, rather
>than just hacking it out, we would all be better off. 

Etcetera, but I can't leave without sideswiping this bromide.  One man's
hacked-out code is another man's correct design.  Everyone's best at
something, not always the same thing.  I have people I would go to in a
moment and say, "Task XAP is crashing every 10 minutes, I need a hack
>>NOW<< to keep it afloat somehow because our customers are screaming at
us!," and know I was in good hands, but would never go to and say "We
need a solid overall design for a portfolio database" because I know I'd
get a mess.  And conversely.

Good design is a great thing, but there is a maxim: 

	Project requirements will grow until your design busts.

Neff's Corollary: No act of good programming goes unpunished.