Archived

This topic is now archived and is closed to further replies.

Alpha_ProgDes

Algorithms....

Recommended Posts

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.)

Share this post


Link to post
Share on other sites
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.

£§

Share this post


Link to post
Share on other sites
Well at first for me I would jump right in and code the day away getting stuck on a lot of bugs or haaving to rework the code becasue I was using a bad design method.

It took some time to learn to write my ideas out in an organized manner but after a lot of practice I''ve found that your code can become ten times better with you putting more effort in researching and developing solutions on paper while experimenting with the real code a little.

Trust me, It can help a lot.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
For algorithms, I often type them out as comments first. Indent the comments as you would indent normal blocks. This helps you see the big picture, rearranging things as needed. Then you can fill in the code around the comments (not replacing the comments!)

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
quote:

For algorithms, I often type them out as comments first. Indent the comments as you would indent normal blocks. This helps you see the big picture, rearranging things as needed. Then you can fill in the code around the comments (not replacing the comments!)



That's pretty much what I do too, minus the indentation (I just number the steps). I start with a set of function/method stubs, use comments to outline the algo and just fill in as I go. For data structures that are much more complex than lists I tend to draw them out on paper and sketch the algorithm outlines around them.

[edited by - JuNC on October 17, 2002 12:18:40 PM]

Share this post


Link to post
Share on other sites
bah dude... the best programmer is the one that doesnt think bout the programming... just the problem...

naturally if you in a group and working for people... they will want to see data and results... in that context you should write out ur code... but when ur just hacking.. just write it... your mind will do all the work without u even thinking about it... hehe..

Share this post


Link to post
Share on other sites
ahhh yeah... u''ll probably have to contact your head if your having to learn a new thing.. like assembly... LOL.. now that takes a while to get used to... hehe... and then yeah... write down a few notes to get the dissired effect... "AhHAAAAaaaa"...

Share this post


Link to post
Share on other sites
quote:
Original post by Kylotan
For algorithms, I often type them out as comments first. Indent the comments as you would indent normal blocks. This helps you see the big picture, rearranging things as needed. Then you can fill in the code around the comments (not replacing the comments!)




yeah.. everyone does this I think... write the function definition... then write down in comments; wot the function is supposed to do...

its quite good... cus if you dont have anywhere to start you can think about what functions you will need... then write them all out... comment them... make revison''s... then start from the top and code them all in one go...

Share this post


Link to post
Share on other sites
There is something called PDL (program design language). It isn''t a language, even though they call it a language. Its a method for writing computer code that involves writing out the algorithm and pseudo-code first. It teaches you the proper way to approach and solve a problem, and it is step-by-step. A lot of people partially follow this method when they code and PDL is just a way of formalizing the process.

Whenever you get something tricky, and you are not sure how to code it, you can always fall back on PDL. PDL is like an algorithm for producing code.

PDL sounds what your teachers were talking about, and what you are looking for. The best place to learn PDL is in a book called "Code Complete", which, by the way is a must read for any serious programmer.

Good luck!

Share this post


Link to post
Share on other sites
Me: as what everyone else has pretty much said Start off using vague psuedo-code, then expand on each line in stages until I end up with my final PDL-esque algo
One thing I always avoid is putting any sort of language specifics into it, this is a general rule of any psuedo code but I''ve seen people do it before .. :|

I recommend Code Complete to everyone, especially my A-Level computing teacher who pretended to barf into his bin when he saw i''d used a "goto" to emulate something RealBASIC can''t do... *sigh* ...

Share this post


Link to post
Share on other sites