Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!killer!pollux!dalsqnt!rpp386!jfh From: jfh@rpp386.UUCP (John F. Haugh II) Newsgroups: comp.misc Subject: Re: Basics of Program Design Message-ID: <3061@rpp386.UUCP> Date: 22 Jun 88 01:11:28 GMT References: <901@td2cad.intel.com> Reply-To: jfh@rpp386.UUCP (The Beach Bum) Distribution: na Organization: Big "D" Home for Wayward Hackers Lines: 64 [ remember kids, this is just the way this lowly hacker does things. your milage may vary. i'm bored, so writing this posting seemed like a nice way to pass a few minutes. - john. ] In article <901@td2cad.intel.com> brister@td3cad.UUCP (James Brister) writes: >This may be a stupid question, and I hope I'm in the right newsgroup. >Send any flames directly to me and I'll shut up. not much else going on. not enough daylight left for a good bike ride, so here goes. >For the past few years my professors have rambled on about data >structures, compiler design and more, ad nauseam. But none of them >have ever mentioned the best way, (or any way really) to go about >sitting down and actually writing a program. yes, colleges and universities don't seem to big on useful information. a friend in college was charged with writing a string length function in C for a compiler writing class so he chose the `elegant' solution. strlen (s) char *s; { if (*s) return (strlen (s + 1) + 1); else return (0); } not such a smart move. always consider the cost of your algorithm. >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? i don't think i've written a flow chart in 3 years, and i've been programming for 10 years now. the methods i've used ranged from hand code, flow chart, keypunch over and over again, psuedo code, and just plain hack at a terminal. my current favorite is a mix of the psuedo code game and hack at a terminal. i just finished 45,000 lines of C this spring, most of which i hacked at a terminal. >What's a good way to organize the writing process? I have all these >great ideas running around in my head that I find difficult to get >out without making mistakes in the task itself. i try to use successive refinements. throw some good ideas on a piece of paper or tube, crank the sucker up, and see where you missed. the most useful thing i find is to get the ideas written down while they are fresh, then work out the algorithms later. and after that, do the final coding. coding isn't such a big deal, algorithms are. worst mistake is to write code to soon. code once writen becomes engraved in stone. always be ready to throw the whole mess away and start again. there is a fantastic text, "The Mythical Man-Month - Essays in Software Engineering" which is a must read. go buy it and read it fifty or a hundred times. - john. -- John F. Haugh II +--------- Cute Chemistry Quote --------- River Parishes Programming | "If you aren't part of the solution, UUCP: killer!rpp386!jfh | you are part of the precipitate." DOMAIN: jfh@rpp386.uucp | -- Some FORTUNE program