Thread: Pseudocodes

Originally posted by face_master
>>
Pseudo-code's the best thing since sliced bread. I dare you to make a big project without any kind of pseudo-code, flow charts, or anything else.
<<

Screw flowcharts. They suck!

Anyways, my retarted teacher is like, "this is exactly how you must do pseudeo code...bla bla bla" and he had it like this:

Code:

BEGIN
   SUM = 0
   INPUT FOO
   DISPLAY "this crap"
END

And i'm like "dude, thats just BASIC but you changed some keywords". "Pseudo code can use whatever syntax suits you". And he's like "No. This is how you must do it according to the Psedueo code Standard" (he pulled the "Psedueo code Standard" out of his .........., if you ask me.

Dammit, I ramble so much...

buahahaha!!!! i use pseudo code in many forms, most often with copious amounts of pencil and paper.

See. My signature..
Never code before desk work.
-------------------------------------:-->

You have taken the wrong side. It is better as early you get it.

>>how's 20+ pages of source without pseudocode?

20 pages is small.

I pseudocode anything I havent done before. But my pseudocode is concept based only and simplifies everything to the point where I'm only working on design and not implimentation. Implimentation is easy.

... Hmm... I just thumbed through a stack of notes on my desk and I realise that most of my pre-coding design is merely a classes definition. Apparently it helps me formulate how the class will preform its task and what it will require to do so effectivly while maintaining an appropriate interface with the outside world.

I see a lot of this:

class UntangleLinkedArray

TLIST * HeldList;
unsigned long RecordCount;
unsigned long RowCount;

TLIST * Untangle(TWHOLE ** Source); //Gives back the untangled source in the form of a TLIST. This is all CMap needs before it calls to render.
TLIST * FeedOneRow(TWHOLE * Source); //Returns a single flat row (to Untangle) from the mess it's going to feed it.
HRESULT IsOnTop(TLIST * ThisNode); //Find out if this is an offset element or if it belongs to another row or if its already sorted (by pure fluke). FeedOneRow will need this before it can pop an element out or it wont know where to put it.

Theres more but thats basically it. I see stuff scratched out all over and re-written. That just proves its better done on paper than scrapping entire function bodies. I guess it just helps me get the design worked out so I dont end up smacking myself two days later going "Doh! I cant untangle like that! There could be offset elements inside other rows! How could I be so stupid?"

Anyhow, pseudocode beats the hell out of rewriting something because of a simple design flaw oversite you would have noticed it you'd plotted the classes flow first.