Usefull Program Planning Methods??

I want to no how you guys plan your projects. I always think of something I want to do, jump right into it, then end up adding new features half way through it that make me get rid of some code here and there, add new code bla bla, but in the end it makes my code sloppy and messy, and hard to follow. Are there any guidelines, tips, tricks, in planning projects? and what kind of naming conventions for variables and procedures do you generally use?

Thanks

 

I do it that way sometimes, just to make creative things.

If there is a production goal in mind, I divide the program into parts with smaller goals for each part, using only about 1/3 of the time I am allotted. This leaves time for debugging and extras that you don't know about, like a router going down or some part of the project you weren't told about. I have a plan for each part and just need to code it. When I get to each part, I'll divide it into several smaller parts until I reach a comfortable starting point, when I know most of the code for that part, and might as well code it.

I will sometimes outline on the computer, and sometimes using paper. That's a matter of preference, and I usually choose the medium depending on the project. Paper can be available while the project is on-screen, or the plan can be in the comments of the code, or a window you can easily switch to. I sometimes use all of these ways, but in most cases I find it best to use paper or an outlining program, then put details in code comments, perhaps using JavaDoc comments, or something similar. This way, you have the details there to code from directly, and the big picture handy, as well.

One more tip, is that I'll code the things I'm most sure of first, then work out the things that have different ways of coding it to see which is best for now, as well as in the future, if it's planned for long-term use and upgrading.

As for naming conventions, mine are non-standard. I wouldn't recommend it, but it's what I'm used to. If you are used to one, I would say stick with it. The names don't matter unless other people will use them or use or maintain your source code. If you know those people, they may have a standard they like. Otherwise, you can see what standard is most common for the people you think will see the names. I usually use the appropriate terminology as variable names in that case, giving the type in the documentation. Sometimes I include the type in the name if I think they will like it that way better, and won't be confused by the added part.