Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mandrill!gatech!udel!rochester!cornell!uw-beaver!microsoft!alonzo From: alonzo@microsoft.UUCP (Alonzo Gariepy) Newsgroups: comp.software-eng Subject: Re: Basics of Program Design Message-ID: <1559@microsoft.UUCP> Date: 25 Jun 88 10:00:51 GMT References: <900@td2cad.intel.com> <3537@pdn.UUCP> Reply-To: alonzo@forward.UUCP (PUT YOUR NAME HERE) Distribution: na Organization: Microsoft Corporation, Redmond, WA Lines: 75 In article <3537@pdn.UUCP> larry@pdn.UUCP (0000-Larry Swift) writes: >In article <900@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes: >>What I mean is: do experienced programmers usually write flow charts, >>or pseudo code. Do they write the whole program out by hand first or >>build it up in their favorite editor? > >Flow charts or state diagrams (I prefer the former) are better thought >organizers, but are difficult to maintain, so pseudo code usually wins out. >However, with flow charts it is difficult to forget about a path. Does >ANYONE write code by hand, anymore? I doubt it. > I do. Write code by hand sometimes, that is. I tend to design solutions before I design a computer system. Then I design a computer system, and then the program. The externals of a program have to be established before you start to design the code. I generally design the code from the top, down. This gives me some idea of the kind of primitives I need and allows the functions of the program to be modularized. I can identify similar tasks that can be merged into single routines (although I favour small routines, and many are called only once). I work my way down to designing the primitives of the system and identifying tricky algorithms and data structures. I start implementation with the primitives, tricky algorithms and data structures. This is where I use paper. The best form of data structures, the most suitable algorithm and implementation, and the correct behaviour and choice of primitives are all interdependent. I tend to sketch these things out on a narrow lined pad with a pencil. The tricky algorithms I often actually code on paper, especially if I have decided that they need to be coded in assembler. Obviously, few programs have very many tricky algorithms. I often use the same tools when putting together an ADT (abstract data type). Perhaps I work on these things best in an organic environment, as opposed to with a vdt in my face, a disk and fan in my ears, and a handfull of keyboard. I don't normally work out the fine points of the top level design until I have done the implementation described above. The majority of most programs is control structures, initialization, error handling, i/o, etc. These things are usually very straightforward and I code them directly into the editor with comments. Keeping routines small puts more emphasis into the design and allows for fewer oversights in coding. My main() routine typically contains only procedure calls with perhaps one or two loops and if statements. Sometimes, when I don't yet know how to do something, I put a comment in instead. The important thing is to know the inputs and outputs of procedures that do transformations on data, and know the mission of procedures that have large side effects. I only use flow charts for designing the flow of information, never for the flow of control. State tables are useful for state driven programs, if you are forced to use an operating system so primitive that it doesn't have multitasking cheap enough to replace a state model. My feeling is that if understanding the flow of control ever becomes a problem, you have made a major design error and should start over. In multi-process programs, complex control flow is replaced by complex message passing. This can become a nightmare if you haven't chosen a good model for process design. With cheap enough multitasking, it makes sense to keep processes small and focused the same as you do with procedures. Proper error handling and resource control in very complex programs dominates many other design and coding considerations. It seems to take many years of hard earned pain before you realize that most useful programs will have added to them new features, a new interface, new machines to run on, etc. It becomes worth the effort to do clean designs up front that save you the agony of patching up bad code later. And let me tell you, bad coding is universal... Alonzo Gariepy Net disclaimUsual