How do you design programs?

is there a good method for designing programs?
kinda like for a report you make an outline so you report has a better "design", I just find myself not good at designing programs.

I do that to but then I get to the point where my code is a big mess

I just get a sheet of paper and draw a general desing plan for the interface or GUI of the program, then i will write in a bit of detail more about the spefic functions of the prog, then i code it :)

Sometimes though i just get half way through making it and cant be bothered to continue, dunno why this just happens to me alot lol.

TNT

I take it one problem at a time, and if I get stuck (which is often) I ask you guys. Also I tend to make one with messy pasted together code, then do it again better.

i usually do the top end stuff, like the interface first, then the low end functions. then once i have the main part working i expand on it. my code is pretty sloppy to, but sometimes i try to clean it up after i'm pretty much done.

I use a lot of paper. First I'll come up with a general idea of what I want the program to do, any features I'd like to have etc... Then I add a little bit of detail to the design, it looks like pseudo-pseudo code. After that I write down what I feel the basic code will look like using functions that haven't been written but I just assume they do what they are supposed to.

Then I write up the actual implementation of the functions, coming up with several different ways to write the more difficult ones just in case my preferred method bombs.

I finally sit down at the computer with hard core code on paper that is probably bug-riddled and write toy programs and the designed functions to make sure that they work before I get wrapped up in a lot more code, I want these functions to work as intended so that I can concentrate on the rest of the program. When making these functions I make sure to step through them thoroughly with a debugger and run them through lint until I get no warnings.

I'll usually write around 20 to 30 toy programs, one for each function that I intend to use. Sometimes more depending on the size of the program. Once I know that the implementation functions work fine I'll start working on the functions that use those functions and test them thoroughly in a similar manner as I did with the implementation functions. I'll then write the main driver to bring the whole program together, run it through lint, step through it and then test it with normal input as well as extreme input to make sure it's more or less idiot-proof.

-Prelude

it depends what you are making...

if you are making a game you absolutely need a design doc...in most cases...

Theoritically, you should do psuedocode or somehow make a sketch of how you are going to make the interface/accomplish what you want to do with the code. But most of us are lazy, and unless it's a huge project or difficult code we don't end up doing it.

Quote:

---

Originally posted by DavidP
it depends what you are making...

if you are making a game you absolutely need a design doc...in most cases...

---

I've read somewhere that two people got a contract with a company after showing them a mere 2 page design doc and a demo.

It depends on the program really. If a lot of memory manipulation is involved (ie, sorting and searching), then I end up drawing a lot of pictures and whatnought. In general, I try to get all my code written down on paper.

This isn't a rule that I've made myself adhere to, it's just that, as I got more and more comfortable with ANSI C, coding this way became more and more natural. When I'm programming in an environment that I am not so comfortable with (like say, Win32), planning kinda goes out the window, and it's back to making up the code as I go along.

There are many methods to do software designing. Some are better in specific cases. SA/SD, Yourdon, Booch, OMT etc. And they use a language to describe the design. At this moment I'm using the OOP method a lot and describe designs with UML. There's a lot of design patterns which lead you to very efficient designs.

Step 0 - IDEA

Step 1 - specification or requirments
Level C - very high and general of what you want the software to do.
Level B - more specific
Level C - specfic algorithms that you want to use

Step 2 - Design - use of flow charts and diagrams that you meet step 1.

Step 3 - Code to the Design

Step 4 - Verify through testing


repating is called software lifecycle

OOAD is the best I have ever found.

basically:
i write, screw up, rewrite, alter, screw up, rewrite, adapt, rewrite, accidentaly delete, rewrite, save, and repeat.
i don't usually bother with pseudocode(but i don't write anything big either).