When I program I tend to do what alot of people do, program and think about what I''m programming while I''m programming. I hope that was clear. My teachers have always told me that writing out an algorithm or pseudo-code (sometimes detailed) before typing even a line of code. I know they''re right. But it''s hard to get the code from my mind to paper then to the compiler. Does anyone have any suggestions or methods they use or know for getting algorithms set before coding? (If this belongs in software engineering or For Beginners please move. Thank you.)

I do a lot of my design while I''m in class. I, like all of you, have or have had classes that are either way too easy or way too boring to pay attention to. So, I hunch over my desk with a pencil and my engineering paper, and write class declarations, algorithms, graphs, or design new concepts for games or whatever.

It works for me, because I _can''t_ have a computer in front of me while I''m in class. There is no option but pen and paper.

You might want to try and put yourself in that position. Go to a park or maybe the top of a hill with a view of the city, or maybe on the bus, or at a wedding.... whichever works for you. Make sure you have a pencil, an eraser, a notebook (graph or engineering paper works best), and definatly a sharpener. Nothing can frustrate me more than a dull pencil. And it gives me a chance to rest for a second and straighten up my back from being hunched over.

For any kind of list, I usually start writing things down unordered. When I think I''ve exausted my list, I''ll start to order them. Lists include functions in a class, features of a program, character types in a game, etc.

For any kind of code, I''ll try and space things out, maybe using every other line. That way, if I realize I forgot a line, I can go back and add it.

Sometimes it helps to write a very basic pseudo-code version of the function before jotting down a more specific code version.

I''m sure I''ve got more ideas in my head, but I have to go to class now. Hrm... which book should I bring to read in class..... Gotta kill time somehow.

Hope this helps.

£§

I seldom have to put things on paper unless it''s like.. A big thing. Then I''ll cover several A4''s with classes, algos etc. etc. :D

I tend to lie/sit in my bed while planning/plotting. I also keep a small piece of paper in my left pocket if I come up with some great idea

That's how I do it too, Kylotan.

I like to "see" the overall architecture of everything I'm doing and then drill down to the details later. I'll put ??'s in my code to make sure I didn't miss anything after I think I'm done (I just search on ??)

In OO programming, I usually only need to do that with more complicated algorithms like loading resource files or doing a complicated parse and test, or the primary routines and loops in the game or engine I'm writing.

I would be interested in mastering a paper-to-code-design methodology involving OO, if there is such a thing. It might help with the things I'm currently stuck on. It can get convoluted in large projects real fast.

[edited by - Waverider on October 16, 2002 8:16:34 PM]

I''d say it depends on your skill level. If you''re just learning a certain topic then you probably can''t plan ahead. But once you know and understand the subject material (having quickly bashed out something ugly that works!) you can go back, plan it out (Kylotan''s comments idea is how I do it too) and fill it in.

pan narrans
Study + Hard Work + Loud Profanity = Good Code

I basically bring along papers and pencil while i'm doing some 'major business' in the toilet/washroom. That's where my concentration is top-notch and i could think deep into problems too. (perhaps too concentrate until i stay there for more than an hour )

[EDIT] Well if i got pc in front of me, i use the Kylotan's way and create empty stub functions.

[edited by - DerekSaw on October 16, 2002 9:33:22 PM]

I think one of the important things in designing is to not get bogged down in details. Don''t think you have to pseudo-code the entire program, just the big picture, usually the main program loop. I take the details, and partition them off into functions and procedures. I define the procedures and what they are supposed to do(but not how). And if I''m lucky those procedures and functions and their associated data will organize themselves rather nicely into classes. And diagrams and whiteboards and discussions and data-flow charts come before pseudo-code.

Just don''t make the mistake I made of trying to write the code without anything to test it on. I finished "writing" the code in six hours. Then it took 6-7 weeks to get it to work.