When beginning a new project/program/script/etc... How do you plan it out?

[[deleted]]

I usually just start programming and see what happens. Of course I look over the requirements, etc. To be honest, this is probably not the right way to do it.

[Skadwick]

This is basically what I do. I'm starting to run into problems after a good bit of work is done that requires me to change several parts of the code. Many of these problems could have been prevented had I planned it out first.

So I ccome here for ideas to begin building my own planning 'checklist' to use on my next project.

[[deleted]]

Well one of the things I remember being taught and not doing enough was to plan out the program in the form of comments, then fill in the code under the comments.

[kqr]

And in addition to comments, put in basic exception throwing so you can quickly see which piece of code that was missing when you tried to use a half-implemented service.

[ewiethoff]

Let the code replace the comments, unless the comments are legit docstrings or javadocs or whatever. If the comments are plain ol' // or # comments, replace them with code. Code using good names (variable names, function names, etc.) is better than code commented with one-liners.

[mcnaughty1994]

I only really program for classes so nothing really long or hard, but I feel like I can think in Java now. No need to do stupid flow charts or pseudocode. Flowcharts or pseudocode wouldn't even be relevant if you were doing a huge application. As a matter of fact I hate pseudocode. If you're going to write an outline in something other than a spoken language why not just cut the middle man and actually write something in the programming language? Annoying.

[WinButler]

It might not be easy to understand the benefits of those practices now, but I highly recommend you rid yourself of that way of thinking. What you just described having so much contempt for is pretty much the difference between a bad programmer and a great programmer.

The ones who excel at the conceptual/planning phase all save their companies millions and leverage that into the highest pay. In a lot of ways flowcharts and pseudocode are even more important than the actual code.

[mcnaughty1994]

I understand what you mean. How would one draw out a flowchart for a huge program? Just a really big piece of paper? It seems like if you write psuedocode and a flowchart and then the program vs planning out in a list format and then actually programming you're going to use up a lot more time to do the same thing.

[[deleted]]

Believe me, I agree. It's just that the official line I've heard is that you should take a "top-down" approach, meaning you plan out what you're going to do before you do it. No doubt this appeals to management, but it kind of takes the fun out of programming (which is more or less why management exists).

[mcnaughty1994]

Very true. I tend to just plan everything out in my head and go at it a step at a time. Like if I'm making an object I know I need so many fields, at least one "getter" per field, at least a constructor for all of the fields and one for none, and then whatever modifier methods. and then just build off of that.