Tue Jul 03 16:00:00 GMT 2001 programmingSubject: Re: Some programming problem of Newbie Date: 4 Aug 1999 10:59:35 +0100 From: csstjds@brunel.ac.uk (John D Salt) Organization: Brunel University, Uxbridge, UK Newsgroups: comp.software-eng In article <7o8q27$u1p$1@nnrp1.deja.com>, Carfield Yim >I know that it is good to writing pesudo code before implentation. >But everytime I want to start to write pesudo code, I don't know how to >start, especially when doing program in visual tools (e.g.:C++ Builder). >And so I keep in delay and delay, at last, I go back to writing code >directly after knowing what should I do. > >I just wonder, how can I train myself to follow good programming >practice? Any book can help me? First of all, I wouldn't worry too much about following your preception of other people's idea of "good programming practice". What's "good" is what's good for you, and programming people have very different individual tastes and practises. Still, whether you use pseudo-code or not, it's pretty obvious that you should have some idea what you want to write before you write it. How much of a "programming plan" do you have before you dive into code? Do you keep hand-written notes beside the terminal as you go along? Do you ever make large changes to what you're coding just to get it to compile? It also matters what style of programming you're attempting. If you're using C++ to create object-oriented applications, I'd say pseudo-code is probably not a good way to get a clear picture of the overall structure of the program. For O-O development, restrict pseudo-code to the internals of individual methods (and many methods will be so simple they don't need pseudocode at all). Use something like CRC cards to help you shape the class structures, responsibilities and interactions. If you still need to write pseudocode but can't seem to get started, try some or all of the following: * Write by hand, not by machine. * Start with the universal problem-solving Nassi-Schniederman diagram: +----------------------------+ | Begin | +----------------------------+ || Solve_Problem || +----------------------------+ | End | +----------------------------+ ...then refine it incrementally. There's obviously no problem "getting started" here, as the start step is the same for everything. Yes, I know it sounds daft, but it works for me. * Try focusing on the data structures first rather than control structures first. * Don't be afraid to throw rough work away, often. * Take a nip of whisky before you start to get the creative juices flowing. It's possible that the programs you're trying to code now are simple enough that you can see the whole answer in your head at once. In this case, pseudo-code (or any other design technique) may seem not to be very useful. If this is the case, try a problem so big or so hard you can't see the whole answer (or even the whole problem!) all in one go. All the best, John. -- John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough Disclaimers: I speak only for me. | to use one of these... you can Launcher may train without warning.| probably manage without one. (google search) (amazon search) second |