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.)