Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!know!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!enea!sommar From: sommar@enea.se (Erland Sommarskog) Newsgroups: comp.lang.misc Subject: Re: SP as "no goto's and nice indentation" Message-ID: <1977@enea.se> Date: 8 Aug 90 20:23:37 GMT References: <9007300920.AA20411@thep.lu.se> <429@e2big.mko.dec.com> <1961@enea.se> Organization: Enea Data AB, Sweden Lines: 39 (Did this one make it to the outer world? Some other I posted last week didn't seem to. Apologies if you see this twice.) Christopher Gillett (gillett@ceomax.dec.com) writes: >Of course, I claim that global variables, like >any good programming language construct, are wonderful things when used >properly and in moderation. Definitely. But very high moderation. My experience after having programmed mainly in various modular Pascal dialects and some Ada is: * Never, NEVER, jamais, non mai, export a variable from one module to another. This will always beat you in the end. * If you have a one-instance structure, for instance a table, it is very good to put it on global level in a module, only accessible through calls to that module. * Sometimes you run in the situation that there are a set of parameters you just pass from routine to routine, giving all routines seven-eight parameters which is not so nice. One solution can be to bundle them in a record type, but sometimes putting some of them on global level in the module might be the solution. Typically parameters from the environment you read once are best handled this way. Also: Declare a variable as close to the point where it used. If you can declare variables in blocks like in C or Ada do so. If your Pascal compiler allows arbitrary order of CONST, TYPE, VAR, FUNCTION/PROCEDURE by all means use it. It has seldom, if ever, happend to me that I've read other someone else's code and thought: "He uses too few global variables". But the opposite is just to common. You see some constants, some type, and then - wham! 30 global variables waiting for you. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se