How do you plan your programs?

Hi, I was just wondering how most people go about planning their programs. Obviously anything for than a few hundred lines needs some thought, but do most people draw a few diagrams and scribble ideas down or do most people prefere something structured, such as UML?

Just curious really cos I wanna make a decent attempt at getting back into C++!

If I can write it all in my head first, fine. Otherwise I write it out on paper without using any planning tools. When I can create logical steps through the program I start to write the code, one class, one function at a time, compiling/building as I go.

DISCLAMER - I am not a professional programmer, and I don't have a CS degree. Mostly, I program as a hobby. I do a little programming at work, but I'm on my own... we are a small company, and we don't have any formal procedures.

Some companies have very strict formal procedures to the point that every function and variable has to be defined, and specified. Complete flow charts and/or psudo code has to be completed and approved before any real code is written. Most companies have at least some guidelines and procedures that have to be followed.

My main approach is to open the editor and write an outline as comments. This might start out as an unstructured list of "stuff the program has to do." But, I will structure it before I start coding. (I wouldn't really call it psudo-code... it's less formal, and more English-like than psudo-code.)

Then I'll start filling-in the actual code, and like elad, I'll test-compile and test-run along the way.

In the process, I'll edit the outline-comments into more normal comments... less wordy and more specific. Note that this is bad engineering practice! I'm distroying the original design document!

Sometimes I'll make an overall flow chart, if I can't visualize the whole concept. This would be a big-picture flow chart... It wouldn't show every function, every branch, etc.

Other times, I'll make a detailed flow chart of some part of the program... again, only if I can't visualize the algorithm, structure, or logic-flow.

As a hobbyist programmer I tend to do what DougDbug does, however I generally maintain the original idea in .txt files. My project folder will usually have a number of similarly named files with dates on the end, like:

project_idea_orig_11-14-04.txt
project_idea_11-24-04.txt
project_brainstorm_12-15-04.txt
...etc

When I get totally stumped on where my design should go, I'll go back and re-read all of these and get back on track, see perhaps why I changed some of the design structure, see what I have changed that really doesn't work and should be changed back, etc.

At some random point when I feel I've structured it properly and I think it'll fly, I'll start pseudo-coding by copying the latest project_..._.txt to project.c and then put /* */ style comment tags around text at random places so that my pseudo-code is commented "properly". When this is done, i'll usually rename the project.c file to project.pseudo.c and then start a clean project.c file and copy/paste or paraphrase my pseudo code lines to the clean file.

If at any point I realize my design won't work, I go back to the .txt files. For my obfuscated code contest entry this process took 3 .txt files and about 3 weeks of on and off playing with how to do it before the "clean" helloworld.c file was complete. (Actually, only a week or so and then a week in between phone calls at work typing up the ASCII for the block letters, and finally about 3-4 days to rename everything to hElLo WoRlD and re-format the source... I found alot more time in the middle of my project when I lost my job... no, they didn't fire me for writing the program heehee) For others I am working on, one has been in the .txt stage for about a year and I don't see an end to it yet, while another has cycled between my .txt stage and pseudo and clean .c stages quite a number of times in a few weeks. That is also where I test sections of my code. For example, write the Card class (for a standard playing card) and then run it through a simple engine to create every possible card and print all the values (including invalid and impossible cards to test error handling). Next, comes the Deck class that uses an array of 52 Cards and a simple engine to test every function in the Deck class (shuffling, sorting, dealing 57 cards from the 52 card deck, etc). Next the Dealer class who uses the Deck, or go back to .txt if the Dealer class doesn't work the way I want it to (maybe incorporate the Deck into a Poker Table instead of a Dealer, or something else entirely).

Oh, and I usually end up working on 3 or 4 or 20 projects at once because I keep losing interest in one and wanting to advance another. Perhaps I should just stick with one project and finish it before I move on to another one, huh?

Big projects get design documents that delineate each module and its interface(s).

Smaller pieces of code (still more than a few hundred lines) get scribbles on a notepad. I'd prefer deeper design thought, and generally write better code when I do that, but I'm too lazy most of the time. It comes back and bites me in the ass a lot.

I was just wondering how most people go about planning their programs. Obviously anything for than a few hundred lines needs some thought, but do most people draw a few diagrams and scribble ideas down or do most people prefere something structured, such as UML?

If you use UML, use cases, sequence diagrams, state machines and class diagrams, along with some type of diagram showing modules, are pretty good. You might also need to write several throw-way protypes during the requirement phase and to test uncertain aspects of the design. When you go to implement, it's then important to test every fairly complex method with a testing framework like cppunit. You might also want to write tests for each scenario.

I plan out the basic structure of my program in my head if it's small enough. I see the functions I will need and try to prototype them. Then I write the contents of the functions.

If it's big (>5k lines), then I'll flowchart it.

I'm sure this is a bad habit, but I haven't planned one of my programs yet except my most recent which is a MUD. On the other hand it can't be to bad right now because the biggest program I've made is probably quite a bit less than 100 lines.