Opinions: How do you "scratch up" you're program?
 

Just curious... but when you all have a great idea of a program, where do you begin?


Do you flowchart? sketch out the structure of the program? sketch out the operation of the program? write it in psuedocode?


Just wondering

Personally? I just start coding:) I'm also probably still considered 'beginner', so I haven't learned the flowchart/structure/operation thing yet. Pseudocode seems pointless to me, because I generally know where I want to start

yep... just start. suss out a crude version of the core function, then flesh out the interface and all that as time goes on.. that's the point of being a hacker.

It depends how big the program is. If it's small enough to keep all the design in memory, I just write it. If it's bigger, I draw module structure and then start the most interesting one. Oh... and if it's GUI, I draw GUI first.

I always try to get the backend working, so all the pieces do the right stuff and just send output to console, file, whatever.. then throw a gui on it when everything is pretty smooth.. regardless of size, my personal projects almost never see paper, unless I run into a design problem(s) as Im going, then ill throw them down on paper...

lol well personally for me, I prefer to write bottom up- getting all the functions, structures, ect/ set up before writing main()

I also like to code write away, excpet when I'm a little fuzzy about what exactly it is I want, in which I just write out what a simple interaction I would havewith the program- so I get an idea of it's Input, Output, and error handling

I am just a beginner and I have tried almost all the ideas mentioned here. If I tend to to create all the submodules first before writing the main() I often endup in incompatible codes. Stubs for whatever that has been created and immediate integration helps me creating the solution quickly.
For larger programs some scribbling on how various classes and modules will interact does help.

Any suggestions and ideas are welcome
:)

Once you get the hang of it- you master possibly the most fundamental UNIX Principals: Get it right the first time


You'll automatically learn how to develop the most efficient and effective code on the first round. Hence you'll find yourself writting "bottom up"- making all your components (functions. structures, classes, etc.) bullet-proof with a clear (and hopefully documented) interface you can use

Never assume you'll be the only one usin it. Personally, I ALWAYS document every component of my programs for future reference. And as a word of advice- keep a change-log on top. It REALLY HELPS you keep track of what you were doing...

Personally I"m self taught, so I'm very comfortable with all this stuff... but still being in High School I have to put up learning *Java*... its sickening


Lucky me I do everything within 10 seconds and my teacher and I both hate java and have the same background in C. So I usually do whatever I want and have begun writing a multiplayer RPG Game on the side. Because we had hurricanes over here- I forgot what part of the game I was working on.... but thank god I had my change log :D!!!

That's funny, I have the same experiance in my programming class(C++, I'm also 17). However, in my class, she always has work for us to do, but I'm way ahead of everyone else. I get the feeling that you also have a much higher skill level than me, I wouldn't know where to start on an RPG game. Ah well.....have fun in programming class:D!

>> (and hopefully documented)

very good point TGWDNGHN, code that is well documented as you go is much more valuable than a flowchart or anything written out on paper. that is a fact that is learned with experience though, hard to get it through when just beginning as youre so focused on the code itself...

>> I have to put up learning *Java*... its sickening

Lol. I know where you are coming from.. I learnt java years ago and have been a sworn enemy of it ever since.. I am c/c++ (prefer pure c++) however, recently I have been seeing that Java is not going away, and the improvement being made to the VM and also to the language itself are not helping it to go away.. I have found myself to be programming more and more in Java recently, I am actually about to get a job in a month in Java, and god forbid c#.. [head in hands] [sobbing].. oh my.. I would give up this in a second for C++, but the plain fact is that it is alot easier to code in Java, so it is much easier to get a job in Java...

thats all the rambling for now.. just hopefully can shine a little light on your dilemma, so you can see that if you learn it, it can be put to use for making cash money.... american currency, not that canadian stuff.. lol (no offense canada)

Funny I always thought it was: "Be prepared to throw the first version away"

It's very rare to get it right the first time but if you have a clear idea of what it is you intend to do then it it much easier to reenginner it to a better solution.

#1. - make it work.
#2. - make it work better.
#3. - make it look pretty.

I remember when I first started programming... I was 9 years old downloading free games off the internet when all of a sudden (being that I am incredibly creative and ambitious) I though "hey... what if I make my own game?!"

That was 7 years ago. Now, for what I program, I have so much experience that I ALWAYS get it right the first time. Thinking logically is second nature to me, so I never give it a second thought.

"Funny I always thought it was: "Be prepared to throw the first version away"

That sounds alot like a Windows Programmer :P


What I meant was that when you write a program, you want the design and interface to bedone correctly from the beginning- NEVER release a (knowingly) faulty or incomplete program and hope to fix it up with patches.

I mean... if oyu look at the code for alot of Linux programs (or at least the man pages, which are still more-or-less resemblant of the modern versions of the programs)- most of the code coems back from 1992 or 1996! Depending on the program, most of them seem as if they have been untouched... at least in a "significant" sense. Even so, you'll still find the older versions working just as fine as ever


They are heavily tested, their design has been carefully outlined and implemented- with a nicely drawn interface that is designed with change in mind.


Now THAT is what I call god programming.


So really... I always get it down right the first time- I don't look back saying to myself "aw shoot, I should have done it this way instead". The Design of the program is usually finalized on the first draft- the actual implementation is somewhat the same way. Sure you might make a mistake, get the order wrong, or realize you could have odne something jus a little more efficient- but those a insignificant degrees. When it comes to programming, a program's quality is best measured against it's design so you know how to work with and interface to it. Then the actual implementation may vary, but is usually not as important unless you have horrible programmers...


Which is why very few people here use Windows :)

"Plan to throw one away; you will, anyhow."
 

The quote is from Fred Brooks - Mythical Man month; quoted and endorsed by Eric Raymond in his The Cathedral and the Bazaar.

Sure it is possible to get trivial programmes working first time but any substantial programme - regardless of platform or language - will result in flaws creeping in. The point that Raymond presses home is that it will happen so be prepared for it because as you rewrite the second solution you will understand the problem much better and so you can produce a better product.

Personally i make some uml diagrams and then use pseudo code, before i even start to code. This method lets you see how thing interact and the best way of doing it, sorting out the logical errors without worrying about syntax errors. After this I then start to code and finish up by optimising any code which is a bottle neck.