Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!rutgers!aramis.rutgers.edu!remus.rutgers.edu!romulus.rutgers.edu!gaynor From: gaynor@romulus.rutgers.edu (Silver) Newsgroups: comp.object Subject: Re: Functions without side effects (was Old confusion) Message-ID: Date: 23 Jun 91 23:06:59 GMT References: <1991Jun19.173 <1991Jun21.013944.23970@netcom.COM> <4174@ssc-bee.ssc-vax.UUCP> <1991Jun23.023559.7391@netcom.COM> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 68 jsl@netcom.com writes: > [Look at the wretched naming conventions typically adopted in C and on the > UNIX platform in general.] I agree with jls here. My own feelings on the lengths of symbols follow. 1. If a symbol is globally accessable, spell it out. If clash avoidance is necessary, put a prefix on it indicating its type or package or something. For instance, suppose I implemented dynamic hash tables in C. (In fact, I have!, mother of all wonders.) Externally referentiable functions tend to look like table_create, table_destroy, table_hash, table_compare, table_define, table_undefine, table_defined, table_put, table_unput, table_get, table_foreach, table_map, etc. 2. If a symbol is only locally accessable, use your best judgement. If it is used in complicated expressions or extremely frequently, make the symbol (or provide an alias that is) an acronym for its intended meaning, and a roadmap. In fact, I tend to do this so frequently, that for consistency's sake, I've made the acronyms my norm. I don't think jls is going to be overly fond of these conventions... :^) I'd certainly name my formal parameters verbosely and provide acronym aliases for all, and use the one which is most appropriate, if I used a language that supported this. Unfortunately, I'm stuck using C for the time being. > As for the C example, be real. Yes, people CAN write readable code in C, and > some even pride themselves on it. A little pride goes a long way. I spend quite a bit of time making sure that my code is good enough to be used and maintained instead of replaced. Some of the people I work with do not take such care. Thousands and thousands of lines of code implement services of whose wonders I shall never partake because of the total and complete lack of external documentation. > Consider, for example, the lovely naming used in UNIX itself: the semantic > content of such commands as "awk", "sed", "grep", "elm", "nn" blah blah blah > is effectively nil. Yeah, pretty bad. `ls', `dbx', `cat', `cd', `tr', `mv', `rm', ..., they should all be spelled out. UNIX provides more than adequate aliasing utilities in its command processors. If someone wants to do a little customization, they are welcome to do so. > Non-hackers--ordinary every day people who are just trying to get WORK done > atop UNIX--don't find UNIX charming or sophisticated or productive or all > those other words hackers used to describe it so glowingly...quite the > contrary, they HATE the damned thing, and that explains why they embrace > graphical, menuing interfaces that isolate them from the grunge of the > underlying UNIX command syntax. I'm not so terribly fond of UNIX. But I do not deny the fact that it is powerful and expressive once you know what you're about. One of the hardest things to swallow is that the provided on-line documentation is written assuming that you know what you're doing, and only need reminding. But because it is powerful, it is very easy to construct less dangerous, more intuitive environments for those who wish or require it. Out of the wrapper, UNIX is definitely not friendly. Which is ok with me, I require a powerful tool, not a friend. In summary, UNIX is pretty powerful, the naming conventions are really cryptic, the documentation assumes foreknowledge, it's trivial to customize. This does not bode well for the novice, but very well for the expert. >> |~~~~~~ Seattle: America's most attractive city... to the *jetstream* ~~~~~~| > Nice .sig! Cleveland: I spent a weak there one day... Regards, [Ag]