[net.lang.c] typedef

COTTRELL@BRL.ARPA, JAMES (08/08/85)

> Typedef is my bugaboo too. When whoever invented it invented it he broke what
> was uptil then a cardinal rule of C........ you could look at a indentifier
> and what was immediately around it and tell exactly what it was
> variable
> array[]
> function()
> "null terminated string"
> 'character'
> along with the non-enforced rule that defined constants were in capitals.
> CONSTANT
> maybe what is needed is some such rule (as for defined constants) that lets
> you know immediately that you are looking at a type name rather than a variable.
> Also at Intel we used to use first letter capitalized to indicate a macro
> function.

I beg to differ. I typedef all my struxures. Makes casts shorter.
	typedef struct foo {
		...
		...
	} FOO, *FOOP;
	FOO	foo = { ...,...};
	FOOP	foop = foo;
	FOOP	barp;
	...
	...
	barp = (FOOP) <expression>;	/* loox better than */
	barp = (struct foo *) <exp>;	/* noisy */

Besides, you've got problems with #defines anyway.

	#define	variable	function()
	#define field		ptr->fld

I suppose you disdain these as well. When used carefully & consistantly,
these can be a boon to readability.

	jim		cottrell@nbs
*/
------

lcc.niket@locus.ucla.edu (Niket K. Patwardhan) (08/10/85)

Re:

#define variable function()
#define field	 ptr->fld

I most certainly abhor such constructs! When you want to know precisely what
a piece of code does, the occurrence of such things makes it practically
impossible. Ever tried debugging a device driver that has function calls
macroed, especially when the macro definitions happen to be in an include
file somewhere? INTELs XENIX drivers arre full of it and horribly buggy!
Yeah yeah! the code looks pretty! but I dont know exactly what it does!

What do you mean by readable anyway? Easy to understand precisely? Easy to
look at? Easy to get the general idea? A program should have it all ways,
if possible.

I would suggest the following:

Easy to get the general idea ---- use comments!

Easy to get the precise operation: -- Use only standard conventions, dont
redefine the language! When you need to compact a complicated mess into
something one can hold in his head, make sure you provide an alert that it is
a user defined something. This way if a reader runs across it
he knows he is supposed to look it up. If it has side effects use something
with () ---- that is the language defined way of packaging complicated side
effects! 

Easy to look at: Use a decent {} convention and be consistent. Keep functions
on one page if possible and use the paging control (^L if you dont have
anything better).  And for god's sake get rid of those nit picking comments 
and stick them where they belong - in the dust at the bottom of your
whiteboard. If there are comments indicating the general
idea of what is going on, keep them well separated from the code, preferably
preceding it in one contiguous blotch, since there usually isn't enough space
and is too difficult to nmaintain in a well separated blotch to the right of
the code! If you insist on putting it there take the trouble to line up
the start of all the comments and to fill the space!

gwyn@BRL.ARPA (VLD/VMB) (08/10/85)

Perhaps more importantly, when you package things in your code,
the packaging should reflect well-formed concepts.  That is,
the packages should have high cohesion and clear meaning.
Arbitrary collection of code fragments into macros fights the
way the human mind functions.

roger@dedalus.UUCP (Roger L. Cordes Jr.) (11/07/85)

	Is the following legal C or not?

		typedef double POINT[3];
		typedef double TMATRIX[4][4];

	Roger L. Cordes, Jr.
	William G. Daniel & Associates
	...!mcnc!ikonas!dedalus!roger

gwyn@BRL.ARPA (VLD/VMB) (11/11/85)

> Is the following legal C or not?
>	typedef double POINT[3];
>	typedef double TMATRIX[4][4];

Sure; why not?
(Note that a jmp_buf is a similar typedef.)