If what I'm doing is small or easy, with no risks involved, I'll jump right in and start coding, fixing bugs and errors afterwards. However, if I'm coding something large or something that I cannot risk messing up (account registration, subscription handling...) I'll create a flow chart and plan things out as carefully as I can beforehand.
Depending on what I am coding, I might also put it into a testbed application before it goes into the main app. This would mostly be done for projects that would be difficult to debug in the larger and more complex main app.
P.S. I am also one of those programmers that thinks of coding while in the shower, heh.
What's your programming style?
Many moons ago I used to just jump in and code...
Believe it or not that was in assembly. I am "too old for that shit" now! Not assembly, you understand, just too old to waste time coding something complex without any planning.
As I have aged I have found that it's a more organic process.
For simple tasks I just code, of course.
For middle to more complex tasks I generally sit and think, make some notes, plan classes, and research if necessary. Writing a good, commented .h file first is always very very helpful.
For really complex R&D I tend to keep it in the back of my mind from day to day, and eventually something will click and then I'll plan, classify, and code...
Of course after all of these things I may well then throw it all away and start again.
One thing I have found to be my best work practice is to maintain two or three versions of a source tree, and an active 'Sandbox' dev copy. The latter I am free to code any mess in, and only once it has been tidied, optimized and 'classed' properly does it migrate to a main set of code. I then manually move code sections to a main dev section. In doing that I re-familiarize myself with both code sets along the way.
Believe it or not that was in assembly. I am "too old for that shit" now! Not assembly, you understand, just too old to waste time coding something complex without any planning.
As I have aged I have found that it's a more organic process.
For simple tasks I just code, of course.
For middle to more complex tasks I generally sit and think, make some notes, plan classes, and research if necessary. Writing a good, commented .h file first is always very very helpful.
For really complex R&D I tend to keep it in the back of my mind from day to day, and eventually something will click and then I'll plan, classify, and code...
Of course after all of these things I may well then throw it all away and start again.
One thing I have found to be my best work practice is to maintain two or three versions of a source tree, and an active 'Sandbox' dev copy. The latter I am free to code any mess in, and only once it has been tidied, optimized and 'classed' properly does it migrate to a main set of code. I then manually move code sections to a main dev section. In doing that I re-familiarize myself with both code sets along the way.
I type up a lot in terms of use cases, feature requirements, and ideas or requirements for implementation, so that I have plenty of information up front. Then I start coding, with the emphasis on getting something working first, and refactoring it into clean code later. My first attempt at anything usually has a few globals and module-level functions, and once I've proven that the algorithm and data structures work to produce the output I want, I remove all the globals and structure it more appropriately.
I never do class diagrams or anything like that though. Generally I know exactly which patterns will apply to my code up front. I find the refactoring into cleaner code to be quite easy when you know you have already met your requirements (which I listed up front), rather than trying to hack extra stuff into a rigid structure that wasn't designed for it.
I never do class diagrams or anything like that though. Generally I know exactly which patterns will apply to my code up front. I find the refactoring into cleaner code to be quite easy when you know you have already met your requirements (which I listed up front), rather than trying to hack extra stuff into a rigid structure that wasn't designed for it.
Quote:Original post by MJPQuote:Original post by Telastyn
Generally I'll think through a problem during the slow parts of the day (bathroom, shower, driving, boring tv, waiting for food) until I'm reasonably comfortable with the solution. Sometimes it requires jotting things down and notes, but that's rare. Then I'll implement things.
I thought I was the only person who thought about programming in the shower! [smile]
All real programmers think about programming in the shower! [lol]
I take a middle-of-the-road approach: "Jump in and plan." I usually set a very simple goal, do a slight amount of planning, and do it. Then I'll think of something else to add, and repeat the process. This process repeats from hello world to finished product.
It's not until I have to make a big jump that I spend more time planning. I'll usually think about it and not get anywhere for a while. Eventually, I'll get enough of an idea that I can get started, refactor a time or two, and it gets done.
Lately, I got the hang of class diagrams, so I've been using those a little. I love diagrams.
Quote:Generally I know exactly which patterns will apply to my code up front.Ah, if only...
Used to to jump in, and code it up. Then usually i would find problems and ended up ripping it apart again.
Bit of a perfectionist, So if its not as good as it could be, its wrong.
Not good in programming...
So now I plan before i code.
Bit of a perfectionist, So if its not as good as it could be, its wrong.
Not good in programming...
So now I plan before i code.
If I'm going to start a new game project, as with most people I used to jump right in and start coding. Now I tend to open up Word and write up a very rough design document, with write up tabular data (abilities, etc.) in Excel. These two files expand as I go along.
I've been on and off on a project for about a year now, which was originally in Gamemaker 6.1 and recently ported it to C#. Gamemaker and the way it handles objects is alot more CPU/memory intensive then using a 'real' language, also it only emulates object-oriented-ness. It was incredibly messy with some code (particularly effects, or buffs) not being able to hide the implementation.
Also I keep a journal of significant milestones with a sheet in excel. This is just because I like to look back on what I've done (in how many days) and it also inspires me to do more.
I've been on and off on a project for about a year now, which was originally in Gamemaker 6.1 and recently ported it to C#. Gamemaker and the way it handles objects is alot more CPU/memory intensive then using a 'real' language, also it only emulates object-oriented-ness. It was incredibly messy with some code (particularly effects, or buffs) not being able to hide the implementation.
Also I keep a journal of significant milestones with a sheet in excel. This is just because I like to look back on what I've done (in how many days) and it also inspires me to do more.
Usually, before I hit the code for an actual project, I spend a bunch of time writing notes and thinking about what it is Im going to be doing. I single out stuff Ive never done before, research, make a few simple test progs to figure it out, and then prepare for the blitz.
The blitz is usually a few days worth of coding, testing, retooling, testing and whatnot, and for me, usually turns out a working componant of a large system for example, that not only works, but wouldnt take forever to modify.
In fact, alot of the planning I mentioned involves thinking about componants and systems Ive already done, figuring out which ones I can reuse, and how theyd need to be changed to make it work. I guess i program in 2 phases, the planning, and then the coding, repeated as necessary.
The blitz is usually a few days worth of coding, testing, retooling, testing and whatnot, and for me, usually turns out a working componant of a large system for example, that not only works, but wouldnt take forever to modify.
In fact, alot of the planning I mentioned involves thinking about componants and systems Ive already done, figuring out which ones I can reuse, and how theyd need to be changed to make it work. I guess i program in 2 phases, the planning, and then the coding, repeated as necessary.
ShowerThinkers++; :D
I think all dev teams should have showers nearby, hold your meetings in shower rooms, get waterproof equipment...Okay that's taking it too far.
There are 3 things that I find are always handy to have around, pen/pencil, notebook paper and grid paper. As for when I'm starting a new project, once I've got my brainstorming done, I basically make a priority/dependency list of all things needed and go down the list one by one. I start roughing out the interfaces of how I think things should initially go, then prioritize them and again go down the list and start implementing them. As I'm going I look for patterns to make generally reusable code from. Usually by the time I get through I've redone a lot of the interfaces so they're easier to use and hopefully less dependent on external things and such.
I think all dev teams should have showers nearby, hold your meetings in shower rooms, get waterproof equipment...Okay that's taking it too far.
There are 3 things that I find are always handy to have around, pen/pencil, notebook paper and grid paper. As for when I'm starting a new project, once I've got my brainstorming done, I basically make a priority/dependency list of all things needed and go down the list one by one. I start roughing out the interfaces of how I think things should initially go, then prioritize them and again go down the list and start implementing them. As I'm going I look for patterns to make generally reusable code from. Usually by the time I get through I've redone a lot of the interfaces so they're easier to use and hopefully less dependent on external things and such.
Agile Development I think it is called. No need for UML schemes etc. Just start to code, if something doesn't work out as expected? Rethink the solution and fix it :). Like I read here before, I think about complex pieces of code during slow parts of the day. Once I have a global design in my head I just code it and refine it.
For my current project during development I created a network flow chart, a summary of all the commands send en from which functions. My code became a little to complex to oversee it at once, so design documents can certainly be useful imho. ;)
For my current project during development I created a network flow chart, a summary of all the commands send en from which functions. My code became a little to complex to oversee it at once, so design documents can certainly be useful imho. ;)
Quote:Original post by Edge Damodred
ShowerThinkers++; :D
I think all dev teams should have showers nearby, hold your meetings in shower rooms, get waterproof equipment...Okay that's taking it too far.
There are 3 things that I find are always handy to have around, pen/pencil, notebook paper and grid paper. As for when I'm starting a new project, once I've got my brainstorming done, I basically make a priority/dependency list of all things needed and go down the list one by one. I start roughing out the interfaces of how I think things should initially go, then prioritize them and again go down the list and start implementing them. As I'm going I look for patterns to make generally reusable code from. Usually by the time I get through I've redone a lot of the interfaces so they're easier to use and hopefully less dependent on external things and such.
LOL! I think you've got something there. And I always have my notebook with me, too. Are we related? Oh, except you have a smarter development strategy than me. *sigh*.
I think even with Agile you're supposed to do a little bit of planning. Then you just implement the plan in little bits so you can change it without having built too much momentum.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
