just a general sort of wonderingment really... how do you go about making programs - do you 1) code everything in long drawn out chunks and then after you''ve finished it all try to build it and fix the errors or 2) do you program a little bit, build it, fix the errors, get it to work properly, program a little bit more, etc... i know i do it the second way, i was just wondering if anyone actually does the first way...

There''s an unwritten law in programming, that you should NEVER EVER try to fix more than one thing at a time. The same law applies to writing new code. Of course, no one abides by this law.

-Jussi

"Hopla"

Hi,

it really depends on what I''m coding. Sometimes when refactoring I''m changing something that has so much influence on other stuff that you simply cannot just do it bit by bit. For the rest, I do everything bit by bit.

I stub a lot by the way. Just giving the interfaces placing a todo in the body of methods for later implementation. That way you can code large pieces at once without really spending time on stuff.

One thing however that I always do is debugging code that''s more then 10 lines if I try it for the first time. I believe it was the CodeComplete book that thought me that and I haven''t regretted trying it ever. When you code a new algorithm just step it through the debugger watching variables here and there and you will find all the stupid little bugs much faster.

At first it seems stupid to debug code that you haven''t even tried running normally before but trust me, in the end you''ll save time!

Just a tip.

Jaap Suter

____________________________
Mmmm, I''ll have to think of one.

quote: Original post by s9801758

One thing however that I always do is debugging code that''s more then 10 lines if I try it for the first time. I believe it was the CodeComplete book that thought me that and I haven''t regretted trying it ever. When you code a new algorithm just step it through the debugger watching variables here and there and you will find all the stupid little bugs much faster.

The problem is that debugging doesn''t always work. Since I moved my game engine''s window handling from the Main class to a separate Window class, with the Main class having a message hook in the main window, my program has crashed the whole computer every time I try to run or debug it. Currently I can only debug by logging. It''s quite annoying. I probably messed something else up in the progress.

BTW. In this case, I also had to write a lot of code without running it, so the "law" doesn''t always apply. But you really should stick to it whenever possible, I talk from experience.

-Jussi

"War for the masses"

I actually went to school with a girl that did it the first way. She was a very good programmer though and the programs were under a thousand lines. She would get clean compiles on the first try and no bugs. It was pretty amazing to me. She also typed about 130 words per minute. The first time she walked in, sat down, typed out the program, ran the test data through and didn''t have any errors I about fell out of my seat. She thought it puzzling that I would think there would be errors. Admittedly she spent a good deal of time in advance working everything out.

Wow, sounds like the perfect woman to me

- Houdini

I code like #2. Maybe because that is I have been programming less than a year, or maybe because my main source file is ~1500 lines.

She sang and danced professionally as well as being quite pretty and a sweet disposition. So pretty much seemed perfect to me to except for one small flaw. She wasn''t interested in me

I generally do a recompile-by-function system.
Since none of my programs have yet exceded ~1500 lines, i don''t have to worry about long times; so generally I compile everytime i finish a new function and attempt to implement it somewhere in the program. If it errors, i keep working until it all makes sense.


This RtS-Babble© has been brought to you by:
-Run_The_Shadows
-Run_The_Shadows@excite.com

I generally follow two sets of rules based upon how large the change is that I have to make. If the change is small then I can usually code the solution, be it 10 lines or 200 lines of code and then debug the whole thing one bug at a time. I find it easier to get the code typed and then refine the algorithm to do what I intended and not what I type.(they usually differ in some small syntax that I overlooked) Debugging is done in any way that is available to me.

When the change is large, I usually try to plan much more. I identify the places in the code that the change will affect. Next, I determine where I have to add modularity or branch functionality in the located spots. Once all of this is done, I mentally work through the code to make sure I didn''t miss anything and come up with a modular test plan to allow me to debug the large change. For instance, if the code has configuration functionality and in-game functionality, I develop a quick test plan for both. If after figuring this out, I can code the solution to a single test plan without needing the others I will edit and compile that way to complete the change, moving on to the second test case when finished. If I can not then I code the whole solution in one shot and get myself a Mountain Dew handy for the debugging session that usually follows.

All in all, I run by the mantra of top down design. Identify the problem as a whole, break it down to smaller modules, then break it down until you have identified everywhere that is affected. Code by following this tree in reverse, testing at major nodes in the problem tree where applicable.

Kressilac