Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!cory.Berkeley.EDU!iverson From: iverson@cory.Berkeley.EDU (Tim Iverson) Newsgroups: news.admin,comp.sources.d,comp.lang.c Subject: How (not) to Program in C (was Re: PD C as solution to binary groups) Message-ID: <3367@zen.berkeley.edu> Date: Fri, 21-Aug-87 21:49:54 EDT Article-I.D.: zen.3367 Posted: Fri Aug 21 21:49:54 1987 Date-Received: Sun, 23-Aug-87 06:35:56 EDT References: <6960@g.ms.uky.edu> <3725@ncoast.UUCP> <2527@whuts.UUCP> <2639@hoptoad.uucp> <1101@laidbak.UUCP> Sender: news@zen.berkeley.edu Reply-To: iverson@cory.Berkeley.EDU.UUCP (Tim Iverson) Organization: University of California, Berkeley Lines: 107 Xref: mnetor news.admin:881 comp.sources.d:1152 comp.lang.c:3812 In article <1101@laidbak.UUCP> guardian@laidbak.UUCP (Harry Skelton(E)) writes: >Simple use of structures or multi-array useage. Well, if all you can write is simple programs, this ain't a bad idea. Some people have more complex needs than yours. If you want simple structures, don't program in C. >No externs or unions (if at all possible). Really! How do you expect to declare the functions in all the other modules? Perhaps you haven't discovered that when functions don't return ints, their return value must be declared (with extern if in a different module or a library). Admittedly I don't often use unions, but occasionaly I found them essential. >straight use of variables - no pointer playing. No pointers? This is one of the nicest things about the language. Without this I'd have to do twice the assembly level programming that I do now. >NO TYPEDEFS - some machines will croak on this. (Hi SCO Xenix) Typedefs are standard K&R. If SCO doesn't support them that's your fault for making a bad buy. >Small moduals - better a few little programs doing something than one big one. Good idea, but you've got it all wrong. A module is not a little *program*. It is a set of routines that perform a common function collected into one object file for easy debugging. Having 10 little programs that do the job of one is not the way to go (almost always). >LOTS OF COMMENTS - nuff said. No. How 'bout *consise* comments. I don't care how many comments there are as long as they're to the point. >Smart makefiles or config programs - to find out what the user does not know (see rn) Well, suppose I have this nifty program in C that runs on WeirdOS Mark IX, and I want to post it. Do you expect me to spend a week writing a makefile that will compile on all of the systems on the net? If so you're going to be disapointed. A better idea would be to suggest that makefiles be provided for the systems the program is advertised to run on. If you want to run it somewhere else, then its up to you to make it go. Stop complaining; there's lots of real nice software floating about the net (for free) and you're complaining because someone won't hold your hand while the stuff compiles. >No BSD or Sys V dependent stuff - must be able to compile 'clean' on any system. While you're at it why don't you say no Pascal or Fortran. Porting C between the two really isn't that hard. Again, this software is free! Don't complain if its not waranted. >vars must have legable names - no pt.dk.i2.dv - put.disk.in2.drive <--- better Nice sentiment, but I'd rather have small variable names in small functions with good function names than than long names everywhere. I'd rather see check_for_errors(foo), than foo(this_might_have_errors). >no memory playing - no mallocs, allocs, callocs or whatever - >if it cant be handled by the compiler then don't post it. This one's got to take the cake for all time stupidity; without dynamic allocation most programs that use lots of memory (editors, graphics, database, compilers, ..., i.e. just about everything) won't be able to run on systems without virtual memory. If you were to choose one way to make a language unpopular, lack of dynamic allocation would be on the top of almost every list. Perhaps 20 years from now, such a statement would have merit, but not everyone today has lots of real or virtual memory. >use standard includes - stdio.h curses.h termcap.h ctype.h ect.... Curses.h and termcap.h are not standard (unless you're talking SysV or BSD :-). If the thing runs on what the poster says it will run on, don't complain. >include complete documents.... Good idea, but I wouldn't insist on it. >oh...main must be on bottom - plexus, IBM xenix (orig versions) and others have >problems with main at top. (TRUE!) This is sick. Are you a Pascal programmer or what? Conceptualy (and traditionaly), main belongs at the top, or for big programs, all alone. >My opinions are not those of my company! Good. If they were, I'd never buy anything your company sells. I really don't see what you're complaining about. All of the software I've gotten off the net has done pretty much what it advertised to do, and alot of the big packages have been very high quality. Considering that all this nice *source* is free, there is no way I'd try to impose restrictions on the style of programming these people indulge in. - Tim Iverson iverson@cory.Berkeley.EDU ucbvax!cory!iverson