Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!hoptoad!academ!killer!jfh From: jfh@killer.UUCP Newsgroups: comp.lang.c Subject: Re: portability and standards Message-ID: <1103@killer.UUCP> Date: Mon, 6-Jul-87 14:35:46 EDT Article-I.D.: killer.1103 Posted: Mon Jul 6 14:35:46 1987 Date-Received: Sat, 11-Jul-87 16:44:27 EDT References: <2290@calmasd.GE.COM> <4715@columbia.UUCP> <107@snark.UUCP> Organization: The Unix(tm) Connection, Dallas, Texas Lines: 78 Summary: Just why did I get a degree? Or When Do I Get To Use Goto's and Global Variables? In article <107@snark.UUCP>, eric@snark.UUCP (Eric S. Raymond) writes: > In article <3399@ihlpg.ATT.COM>, bgb@ihlpg.UUCP writes: > > > > [a sensible technique for preventing inconsistencies in globals usage] > > > > I submit, though, that this whole discussion rests on a false premise -- > that it is somehow a Good Thing to have a separate globals module with no code. > Every time I've seen such a module it has been evidence for poor data > design in the program. Globals are bad style, the data design equivalent > of goto statements. I have written code that needs goto's to keep from growing into a massive maze of if-then-else's, unneeded functions, and totally unreadable code. The goto is nice when you want to give up, or handle a special case - if you go using it as a way to avoid for, while and do loops you need to have your head examined for remnants of FORTRAN or BASIC. But then I follow some-body-or-other's advice and *document* my goto's with come-from's - i.e. How Did I Get Here? > The major difference between abstract data type (ADT) decomposition and the > more primitive kind of functional decomposition that Algol-descended languages > like Pascal and C were designed to support is precisely the status of > global data. I thought C came from BCPL? And besides, what the h*ll is he saying here? I used globals in Pascal whenever they were needed. Some variables get to be a real bother to pass all over gods creating, and wrapping them up into a big structure you pass all over the place is a bother. > In fact, in > an ADT design environment you quickly develop a perception that globals > are ugly, because they represent places where the data elements of what > should be ADTs are leaking into each other. All this is good and fine for toy code. No, I take that back. Somethings *do* work as ADT's very well. But the entire world does not live in ADT land. What do you do with a simple status variable like errno that is modified by all of the system calls? Add pointers in the file status blocks to all point to errno? Ask a VMS programmer wether they prefer FAB's and RAB's to file descriptors and errno. > [Returning to earth now...] Please do. > C wasn't particularly designed for ADT building, but it's powerful enough > to support it pretty well. In my C code, each .c source file implements an > ADT and has an associated .h file that defines the interface. > [ stuff deleted ] There may be lots of data areas that are > publically visible, but there are no 'globals' that aren't definitely owned > by some ADT somewhere. Sounds like nice design, when it applies. But what if the variable has to live for quite a while, is used by 15 or 20 routines, and isn't all that abstract? For example, a file descriptor returned by a special file open routine? > I find this approach leads to code that is cleaner, better organized and > much easier to maintain. The mental effort required to identify would-be > 'globals' as part of an ADT including their handler code is usually > fairly trivial, nor is there any run-time overhead necessarily involved > in partitioning things this way. I suppose all of the ADT glue is useful for libraries and packages that are used many times, and may have many different functions. Well de[fs]i(n|gn)ed interfaces do not exclude global variables however. Nor do global variables have to produce unreadable code. That seems to be what /* */ are for - to add some intelligence to the source code. The most readable code I've seen has tended to be assembler - for just that reason. Every assembler programmer I know has always documented well, even to excess in many occasions. The best C code is the same way. Look at the source for the chess program that was just posted. I seem to remember that it was well documented. That or rogue, I forget ... - John.