How much planning is recomended before you start to code?
I have been at both extremes...
Things where everything was planned out first - down to every routine in the code. Everything had pseudo-code, flowcharts, variable lists etc. This was quite difficult and took quite a while, also it''s almost impossible to consider all the issues until you have things up and running (or not, if you get it wrong!). I must say that coding the routines (this was in 68000 assembler) was really, really easy when working from the flow-charts, and most code worked 100% (probably just luck). Having said all of that, I would not recommend this approach, these days I feel it was all just a bit over the top.
At the other end of the extreme is no planning at all. We have all done this, and it''s never pretty! Things are hard to change, bugs are hard to find and fix, code is messy, and you end up scrapping everything and starting again.
These days I tend to fall somewhere in the middle, plan to a certain point where I feel I have a complete understanding of what I am trying to achieve, then start coding it. If something comes up which is hard to visualise, I will get the pen and paper out again. Added to this is a good dose of regular refactoring as I go. This is the approach that works best for me. But eveyone is different - I guess most people just do what feels most comfortable.
Things where everything was planned out first - down to every routine in the code. Everything had pseudo-code, flowcharts, variable lists etc. This was quite difficult and took quite a while, also it''s almost impossible to consider all the issues until you have things up and running (or not, if you get it wrong!). I must say that coding the routines (this was in 68000 assembler) was really, really easy when working from the flow-charts, and most code worked 100% (probably just luck). Having said all of that, I would not recommend this approach, these days I feel it was all just a bit over the top.
At the other end of the extreme is no planning at all. We have all done this, and it''s never pretty! Things are hard to change, bugs are hard to find and fix, code is messy, and you end up scrapping everything and starting again.
These days I tend to fall somewhere in the middle, plan to a certain point where I feel I have a complete understanding of what I am trying to achieve, then start coding it. If something comes up which is hard to visualise, I will get the pen and paper out again. Added to this is a good dose of regular refactoring as I go. This is the approach that works best for me. But eveyone is different - I guess most people just do what feels most comfortable.
Failing to plan, is planning to fail.
Planning to plan, is failing to fail.
Those who don''t plan, teach. Those who fail, teach gym.
Planning to plan, is failing to fail.
Those who don''t plan, teach. Those who fail, teach gym.
Author
I didnt expect so many replies so soon. thanks all you guys were helpful 
I have a window class which is abstract enough to create any window, main app window or child using system defined classes. I use this code to make an OpenGL window class. So the OpenGL window has an "is a" relationship to window. My small problem is that right now the OpenGL window can only be a main window. It would be trivial to redesign the class to make it be a child instead of a main window. So far this seems to be my "only" issue. Later on when I start to learn DirectX I can reuse the window class to create a DirectX window. I made sure I named the members with a prefix to avoid problems with name clashes as can occur when you are inherating.
Well I guess I asked what I am in for because all seems to be going well, but its better to be safe than sorry.
I have a window class which is abstract enough to create any window, main app window or child using system defined classes. I use this code to make an OpenGL window class. So the OpenGL window has an "is a" relationship to window. My small problem is that right now the OpenGL window can only be a main window. It would be trivial to redesign the class to make it be a child instead of a main window. So far this seems to be my "only" issue. Later on when I start to learn DirectX I can reuse the window class to create a DirectX window. I made sure I named the members with a prefix to avoid problems with name clashes as can occur when you are inherating.
Well I guess I asked what I am in for because all seems to be going well, but its better to be safe than sorry.
Do some googling for "extreme programming" if you aren''t a fan of big up front design. Or even if you are :-)
Planning *requirements* is essential. How can you start building if you don''t know what you''re building? The benefits of doing a lot of upfront design, diagrams, documentation, etc. are debatable.
--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com
Planning *requirements* is essential. How can you start building if you don''t know what you''re building? The benefits of doing a lot of upfront design, diagrams, documentation, etc. are debatable.
--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com
I start out with a design document (which, I almost never read once it''s done), then I make a technical document then I start coding. Although I REALLY REALLY REALLY REALLY want to start coding right now I''m not finished with my tech doc which is taking forever 
Could someone give a small example of a program documentation?
Close your eyes, and die in the dark...
Close your eyes, and die in the dark...
Author
quote:Original post by x3verge
Could someone give a small example of a program documentation?
Close your eyes, and die in the dark...
taken from stl_vector.h
/** * Returns a read/write iterator that points to the first element in the * vector. Iteration is done in ordinary element order. */ iterator begin() { return iterator (_M_start); } /** * Returns a read-only (constant) iterator that points to the first element * in the vector. Iteration is done in ordinary element order. */ const_iterator begin() const { return const_iterator (_M_start); }In a header I think its every function/class should have a sescription of what it does.
This would be inline documentation.
my general opinion on planning is that you can''t really plan things in detail unless you know exactly how they work, so learning things along the way isn''t really possible. to make a really detailed plan/design you have to know (or learn) how to do everything that will be in your game (or whatever) before you can consider everything. for that reason i tend to just have a general idea of what things will do and not care about how until it comes to writing them. sometimes this plan goes wrong where you find something you thought was really easy is actually impossible causing you to rethink/rewrite a few things, but that''s all part of learning. unless you have loads of experience you can''t plan for everything, so my designing consists of thinking about different parts and what they do, and then when it comes to actually writing them i think for a few days/hours/minutes about how to actually do it and integrate it with the rest of my program. basically the "jump off that bridge when i get to it" approach.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
