[net.sources] long names in 'C' programs

ignatz@aicchi.UUCP (Ihnat) (05/17/85)

All right, people...

If you insist on making 'C' programs look like COBOL by using
32,767 character names, the *very* least you can do is make the
damn things unique in the first 7 characters, OK?

This long-name-chauvinism is annoying enough in sources posted to
net.sources, but now I'm running into it in sources for paying business
purposes, and it's, frankly, intolerable.

One of the greatest assets of 'C' is its great degree of portability.
But there are tens of thousands of binary-license 'C' compilers out there.
These people don't have the freedom to modify their compiler; and when
they pay some outside joker to write something in 'C', and he/she writes
it with 15-character variable names that are only unique in the last 2
characters because "compilers should be able to handle it, and it's
conceptually desirable", or some such drivel, they can't regenerate it
on their system.  What then?  Yep.  They pay twice, to have someone else
fix the code.

C'mon; all 'C' compilers that I know of will accept very long variables,
just chopping off the excess characters.  I'll read your bloody Dickensian
novels, if I must, but fer Crissakes, at least do it in a portable, intelligent,
and reasonable manner.  (No, don't tell me that I can write or get a
preprocessor program to mung the source--this makes debugging and
understandability even more of a joke than it already is.)

	In High Dudgeon,


-- 
	Dave Ihnat
	Analysts International Corporation
	(312) 882-4673
	ihnp4!aicchi!ignatz

aeb@mcvax.UUCP (Andries Brouwer) (05/20/85)

In article <476@aicchi.UUCP> ignatz@aicchi.UUCP (Ihnat) writes:
>
>If you insist on making 'C' programs look like COBOL by using
>32,767 character names, the *very* least you can do is make the
>damn things unique in the first 7 characters, OK?
>
>This long-name-chauvinism is annoying enough in sources posted to
>net.sources, but now I'm running into it in sources for paying business
>purposes, and it's, frankly, intolerable.
>
>One of the greatest assets of 'C' is its great degree of portability.
>But there are tens of thousands of binary-license 'C' compilers out there.
>These people don't have the freedom to modify their compiler; and when
>they pay some outside joker to write something in 'C', and he/she writes
>it with 15-character variable names that are only unique in the last 2
>characters because "compilers should be able to handle it, and it's
>conceptually desirable", or some such drivel, they can't regenerate it
>on their system.  What then?  Yep.  They pay twice, to have someone else
>fix the code.

Yes, that is what happens if you meet such a program once a year.
But now suppose you got such a program every week. Wouldnt you
instead buy a better compiler/loader?

It is reasonable to expect that new compilers accept programs that were
written long ago, but it would prevent all progress if one required
that new programs not use any features that were introduced into the
language in the past ten years.
	("My compiler cannot handle two-dimensional arrays of structures";
	"mine barfs on unsigned bit fields"; "mine doesnt like functions
	returning structures"; "mine dumps core on long int cases in a switch";
	"mine cannot evaluate arithmetic expresssions with more than five
	levels of parentheses"; "mine cannot initialize structs";
	"mine doesnt translate register char's correctly"; "my preprocessor
	produces garbage when identifiers of more than 16 chars are #defined";
	"my C compiler handles 10 char identifiers, but my loader retains
	only the first 6 symbols" - etc. [These are actual complaints.]
	Do you have a crappy preprocessor/compiler/loader? Too bad.
	You may choose between buying a better compiler and wasting some of
	your time each time you have to port something to your machine.)
The more programs are written in rich dialects of C the stronger the
pressure will be on compiler writers to produce compilers that perform
better than minimally.

Quite a different point is that identifiers may be mechanically generated
in some systematic and meaningful way, and in such cases it might be a pain
to distort the identifier generation scheme in such a way that no identifiers
longer than 16? 8? 7? 6? symbols are generated.