taylor@hplabsz.HPL.HP.COM (Dave Taylor) (08/12/87)
Harry Skelton (guardian@laidback.UUCP) suggested in news.admin the following set of guidelines for posting sources to the network. Since it's so amazingly inane I thought I'd actually spend some time to refute what he suggests. If you don't agree, well... Life is like that some times, I guess. [I've numbered the original points for ease of reference] >1. Simple use of structures or multi-array useage. I don't see what the point of this is - part of the point of having a rich set of data structures available within C is to allow people to create data structures that are appropriate for the task they are attempting to solve - reference the book "Fundamentals of Data Structures" if you'd like more information on why simple structures and/or multi-array usage isn't enough. >2. No externs or unions (if at all possible). As with gotos, externs and unions have their place in complex programming tasks. For one example, try getting the value of "errno" without previously defining it as an "extern int" in your program... Unions might be more reasonable to try to limit, however, since they really are susceptible to different machine architectures. >3. straight use of variables - no pointer playing. Again, what do you mean by 'pointer playing'? There are certain times when you need to be able to hand pointers to pointers to structures or whatever else might be needed. >4. NO TYPEDEFS - some machines will croak on this. (Hi SCO Xenix) Tough luck. Typedefs are part of the standard K&R C as defined in many places (including the K&R `The C Programming Language' book). If some compilers can't handle it, then tough luck. (I'll expand on this topic in a second...) >5. Small moduals - better a few little programs doing something than one > big one. That certainly fits in with the Unix philosophy. I agree. >6. LOTS OF COMMENTS - nuff said. Better yet - lots of *meaningful* comments. I've seen too much code floating around (esp. from AT&T and UCB) that has either no comments, or comments that are just stupid and a waste of space. Neither has any purpose or is helpful... >7. Smart makefiles or config programs - to find out what the user does > not know (see rn) Sounds reasonable - how about a tool for helping people create these funky Makefiles? >8. No BSD or Sys V dependent stuff - must be able to compile 'clean' on > any system. This one is obviously a joke. While it is unfortunate that there is such a difference between BSD and SYSV, there are a number of packages floating around that more-or-less allow you to run the code written for one machine on the other ('cept for job control on SYSV). The problem with this is that the person who writes the original code should be thanked for making it available, not forced into digging up other machines and testing the code on them before releasing it. THAT is the job of some volunteer who finds the program sufficiently interesting that they are willing to put the time in to port it and then post the diffs (or what- ever) to the net... >9. vars must have legable names - no pt.dk.i2.dv - put.disk.in2.drive A fine sentiment, but you have quite a weight of programmers that would disagree in actions -- consider the examples in the book ``Algrithms + Data Structures = Programs'' by Nikolas Wirth - they are neat little programs, but the naming conventions and formatting of the listings is about as bad as in any book I've ever seen. (there are, of course, constraints w.r.t. page space, but still...). The problem is that most programmers learn how to program in environments where identifiers are only 6 or 8 characters significant and so they learn that instead of using variables like "ready_to_update" they use "update" or "u" or "rtu" or something equally cryptic. (of course it should also be pointed out that many lint's, even on machines with "arbitrary length identifiers" still get unhappy if two variables aren't unique in the first 8 or 10 characters...) >10. no memory playing - no mallocs, allocs, callocs or whatever - if it can't be handled by the compiler then don't post it. This one I strongly disagree with. If you look at the Elm System sources you'll find that I include and use my own "palloc" permanent-alloc routine. The reason I do this is because the program is pretty memory intensive and I start up by allocating about 75 strings that are never free'd again. So doing it via my own routine allows me to avoid the major 75-entry traversal for each subsequent call to malloc/free that I make. It is a *noticable* improvement on slower machines. (I suspect that the reason you put this in was because you don't under- stand how malloc works and how a typical large software system uses it) >11. use standard includes - stdio.h curses.h termcap.h ctype.h ect.... Standard based on what? Posix? Xopen? SVID? BSD4.2? This is unfortunately pretty useless as a guideline. >12. include complete documents.... Sounds reasonable, but the majority of people who write these large software systems that are released to the network can't write a clean set of documents if their lives depended on it. There ain't no way around this, and I don't think that crummy documentation is much better than none at all (or a man page, as a minimum)... ---------- In general, the problem with guidelines of this nature is that they ignore some of the fundamental problems rather than addressing them. I see the main problems we're talking about here as a combination of the lack of viable standards already implemented in the Unix community (e.g. POSIX or X/OPEN), the lack of proper education for those people who submit some of the poor programs to the net, and generally a lack of thinking on the part of the people who immediately criticize posted software -- the way I look at it it is just as easy (no - easier) for people to write some neat software and just keep it to themselves, so if they're willing to `expose' themselves to the network community at large then they should be THANKED and other people, instead of whining about "it doesn't work on BSD1.04" should be working on finding someone with the knowledge and interest to do the port... Ah well, that's my nickel. -- Dave Tayeue: