AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (02/10/89)
>Date: Thu, 9 Feb 89 12:30:00 CDT >From: MSER001%ECNCDC.BITNET@UICVM.UIC.EDU >Subject: (What really is source?) > >I must say...What is the difference between Good source code...and a >kludge? > >Where in this world do you learn how to create Source Code in a >neat and orderly fashion...so you yourself can understand it in 8 >months...or someone that has never seen the programs source >code...can fix your rotten BUGS! In my opinion you already answered part of your question: Good source code is something that you can understand yourself later and that someone who has never seen the code before can understand, fix, adapt, and extend. >Do we have to resort to getting rid of our complex thinking, and go >for the dull programs? No! It's not necessary for complex programs to have hard-to- understand source code or for simple programs to have easy-to- understand source code. There's no magic forumla that will guarantee your source code will be easy to write, understand, and maintain, but here are a couple ideas that I think are good, and that I use in my own programming: --Use Abstract Data Types (ADTs). You can (and should!) read about ADTs in a good Comp Sci textbook (like _Data Structures and Algorithms_ by Aho, Hopcroft, and Ullman). Very briefly, the idea is to have, for each data type, a collection of routines that have the _sole_ right to deal directly with that data. This leaves you free to _change_ the way that data is actually stored in memory simply by changing the small collection of routines. No other parts of the program will need to be changed. --Break your program into modules (collections of routines) that interact with other modules only by calling the routines in those modules. _Don't_ let modules fiddle with other modules' private variables! --Don't write the same code more than once: If two pieces of code are doing the same thing, they should both be calling a routine that does the job. If a change is needed later, you'll only have to change it in one place. --Organize the program so that changes or additions don't force you to go through the whole thing looking for things that might need to be changed. In other words, avoid making assumptions that will become invalid later. For example, in an Apple IIgs program that uses windows, you might allow the user to open up an arbitrary number of windows containing editable text. _Don't_ write the program _assuming_ that all the windows will be that kind. Later you might want to add another kind of window. Take an _extensible_ approach from the beginning. (For example, GS windows have a 4-byte "refcon" (Reference Constant) for use by your program. Use it to point to a record telling your program what kind of window it is. You can put other info in the record that can have different meanings for each kind of window. This approach lets the user open an arbitrary number of windows, and it's simple to add new kinds of windows to your program.) --Things like indenting and capitalization don't matter too much as long as you're consistent. --I generally don't use GOTOs in Pascal or C, but occasionally they are actually the best choice. Usually other control structures are more appropriate. --Don't use algorithms you don't understand. Take the time to study and understand them first. --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons